[Bug tree-optimization/120702] Extraneous string constant at -Os
rguenth at gcc dot gnu.org
gcc-bugzilla@gcc.gnu.org
Wed Apr 29 07:26:40 GMT 2026
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120702
--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
I think we can retain all important optimization by restricting the aggressive
replacement by constant to where it is likely creating followup optimization
opportunities - which is for register type replacements.
I'll note that size wins are not always obvious:
000000000000001f <benchmark>:
1f: 48 8b 05 00 00 00 00 mov 0x0(%rip),%rax # 26
<benchmark+0x7>
26: 48 89 05 00 00 00 00 mov %rax,0x0(%rip) # 2d
<benchmark+0xe>
2d: 8b 05 00 00 00 00 mov 0x0(%rip),%eax # 33
<benchmark+0x14>
33: 66 89 05 00 00 00 00 mov %ax,0x0(%rip) # 3a
<benchmark+0x1b>
3a: 31 c0 xor %eax,%eax
3c: c3 ret
vs.
000000000000001f <benchmark>:
1f: 48 b8 4a 32 4f 5a 46 movabs $0x463035465a4f324a,%rax
26: 35 30 46
29: 66 c7 05 00 00 00 00 movw $0x4c59,0x0(%rip) # 32
<benchmark+0x13>
30: 59 4c
32: 48 89 05 00 00 00 00 mov %rax,0x0(%rip) # 39
<benchmark+0x1a>
39: 31 c0 xor %eax,%eax
3b: c3 ret
so for the attached testcase the inline copy is 1 byte shorter. I'll
note this can be still inline expanded at RTL expansion (block-copy)
or possibly even later.
I'll note the other internal improvement to disallow &STRING_CST in GIMPLE
by introducing CONST_DECLs cannot fix this issue given the STRING_CSTs
can be part of a constant initializer of a larger aggregate that we may
not be able to elide. That might also be a correctness issue with regard
to the address of such parts. Not constant folding a string part of such
initializer might also keep that whole variable live only for a possibly
small part.
And I bet not constant folding the STRING_CSTs will break diagnostic
testcases relying on such constant folding (moderately easy to fix
by slapping fold_const_aggregate_ref in those places).
Testing a trivial patch.
More information about the Gcc-bugs
mailing list