Significant Increase in binary size and stack usage with clang 18.x

[MarcoSpeziali]

Greetings,

I've encountered a significant change in the behavior of clang's LLVM-IR emission between versions, specifically when comparing the output of clang 17.0.1 with the trunk version for the RISC-V rv32gc target. The IR and the resultant ELF file sizes show a marked increase in the .text section size, with a difference of approximately 1200 bytes (from 0005e8 to 000a88).

This issue is not confined to the RISC-V target alone. I have observed a similar pattern with a fork of the llvm-project (updated to the release/18.x branch two days ago) for our custom backend.

Furthermore, it appears that the clang version 18.x and later are utilizing significantly more stack space, which has led to stack overflow errors in our testing environment (having just 2K of RAM).

For reference and further examination, I have provided an example here: https://godbolt.org/z/qeTae411h.

Could there have been changes in clang's optimization strategies or IR emission patterns from version 17.0.1 to the trunk that might explain these observations? Any insights or suggestions on mitigating these issues (perhaps some new compilation flags)?

[llvmbot]

@llvm/issue-subscribers-backend-risc-v

Author: Marco Speziali (MarcoSpeziali)

Details

Greetings,

I've encountered a significant change in the behavior of clang's LLVM-IR emission between versions, specifically when comparing the output of clang 17.0.1 with the trunk version for the RISC-V rv32gc target. The IR and the resultant ELF file sizes show a marked increase in the .text section size, with a difference of approximately 1200 bytes (from 0005e8 to 000a88).

This issue is not confined to the RISC-V target alone. I have observed a similar pattern with a fork of the llvm-project (updated to the release/18.x branch two days ago) for our custom backend.

Furthermore, it appears that the clang version 18.x and later are utilizing significantly more stack space, which has led to stack overflow errors in our testing environment (having just 2K of RAM).

For reference and further examination, I have provided an example here: https://godbolt.org/z/qeTae411h.

Could there have been changes in clang's optimization strategies or IR emission patterns from version 17.0.1 to the trunk that might explain these observations? Any insights or suggestions on mitigating these issues (perhaps some new compilation flags)?

[MarcoSpeziali]

@dtcxzyw I don't really think this issue should be marked as a regression of the risc-v backend. I have the same issue with my backend, the problem I think is in the generated IR

[dtcxzyw]

cc @topperc

[antoniofrighetto]

I'm taking a look, although it seems like all the memcpys for initializing the buffers have been replaced by a single pair of GEP + store.

[llvmbot]

@llvm/issue-subscribers-clang-codegen

Author: Marco Speziali (MarcoSpeziali)

Details

Greetings,

I've encountered a significant change in the behavior of clang's LLVM-IR emission between versions, specifically when comparing the output of clang 17.0.1 with the trunk version for the RISC-V rv32gc target. The IR and the resultant ELF file sizes show a marked increase in the .text section size, with a difference of approximately 1200 bytes (from 0005e8 to 000a88).

This issue is not confined to the RISC-V target alone. I have observed a similar pattern with a fork of the llvm-project (updated to the release/18.x branch two days ago) for our custom backend.

Furthermore, it appears that the clang version 18.x and later are utilizing significantly more stack space, which has led to stack overflow errors in our testing environment (having just 2K of RAM).

For reference and further examination, I have provided an example here: https://godbolt.org/z/qeTae411h.

Could there have been changes in clang's optimization strategies or IR emission patterns from version 17.0.1 to the trunk that might explain these observations? Any insights or suggestions on mitigating these issues (perhaps some new compilation flags)?