[Bug rtl-optimization/102627] [11/12 Regression] wrong code with "-O1"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102627 --- Comment #5 from CVS Commits --- The master branch has been updated by Vladimir Makarov : https://gcc.gnu.org/g:9046e0d46fc285e5c59c87182d48c8de0f7f929c commit r12-4256-g9046e0d46fc285e5c59c87182d48c8de0f7f929c Author: Vladimir N. Makarov Date: Fri Oct 8 10:16:09 2021 -0400 [PR102627] Use at least natural mode during splitting hard reg live range In the PR test case SImode was used to split live range of cx on x86-64 because it was the biggest mode for this hard reg in the function. But all 64-bits of cx contain structure members. We need always to use at least natural mode of hard reg in splitting to fix this problem. gcc/ChangeLog: PR rtl-optimization/102627 * lra-constraints.c (split_reg): Use at least natural mode of hard reg. gcc/testsuite/ChangeLog: PR rtl-optimization/102627 * gcc.target/i386/pr102627.c: New test.
[Bug rtl-optimization/102627] [11/12 Regression] wrong code with "-O1"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102627 --- Comment #4 from Vladimir Makarov --- (In reply to Jakub Jelinek from comment #3) > The assembly difference r11-8007 to r11-8008 is: > --- pr102627.s2021-10-06 06:32:46.0 -0400 > +++ pr102627.s2021-10-06 06:33:00.0 -0400 > @@ -77,10 +77,10 @@ main: > movq%rdx, %rcx > movq%rax, %rdx > movqe(%rip), %rax > - movq%rcx, 8(%rsp) > + movl%ecx, 12(%rsp) > movzbl f(%rip), %ecx > salq%cl, %rax > - movq8(%rsp), %rcx > + movl12(%rsp), %ecx > movq%rax, %rsi > movl$0, %edi > callw > I believe y returns the 128-bit struct g return value in %rdx:%rax pair, > right before the above instructions, and the above change means that instead > of spilling the whole 64-bits of %rcx that holds at that point u.j and u.k > members (u.k in the upper 32 bits of %rcx) it spills just 32-bits of %ecx > and fills it back in, effectively setting u.k to 0. The w call then takes > %rdi, %rsi arguments it doesn't use and the TImode in %rcx:%rdx pair, but > with the high 32 bits of the TImode value lost. The reason for the spill is > clear, the shift instruction needs that register... Jakub, thank you for the analysis. I believe the patch in question just triggered a bug in hard reg live range splitting. I am working on the PR. I hope to fix it on this week or at begining of the next week.
[Bug rtl-optimization/102627] [11/12 Regression] wrong code with "-O1"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102627 --- Comment #3 from Jakub Jelinek --- The assembly difference r11-8007 to r11-8008 is: --- pr102627.s 2021-10-06 06:32:46.0 -0400 +++ pr102627.s 2021-10-06 06:33:00.0 -0400 @@ -77,10 +77,10 @@ main: movq%rdx, %rcx movq%rax, %rdx movqe(%rip), %rax - movq%rcx, 8(%rsp) + movl%ecx, 12(%rsp) movzbl f(%rip), %ecx salq%cl, %rax - movq8(%rsp), %rcx + movl12(%rsp), %ecx movq%rax, %rsi movl$0, %edi callw I believe y returns the 128-bit struct g return value in %rdx:%rax pair, right before the above instructions, and the above change means that instead of spilling the whole 64-bits of %rcx that holds at that point u.j and u.k members (u.k in the upper 32 bits of %rcx) it spills just 32-bits of %ecx and fills it back in, effectively setting u.k to 0. The w call then takes %rdi, %rsi arguments it doesn't use and the TImode in %rcx:%rdx pair, but with the high 32 bits of the TImode value lost. The reason for the spill is clear, the shift instruction needs that register...
[Bug rtl-optimization/102627] [11/12 Regression] wrong code with "-O1"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102627 Jakub Jelinek changed: What|Removed |Added Last reconfirmed||2021-10-06 Target Milestone|--- |11.3 Component|tree-optimization |rtl-optimization Priority|P3 |P2 Status|UNCONFIRMED |NEW CC||jakub at gcc dot gnu.org, ||vmakarov at gcc dot gnu.org Summary|wrong code with "-O1" |[11/12 Regression] wrong ||code with "-O1" Ever confirmed|0 |1 --- Comment #2 from Jakub Jelinek --- Started with r11-8008-g4bbd51afaa4a3c116fb538d912b35e126be80b41 (at least on the #c1 testcase at -O1, I don't see any aliasing issue nor any other UB in the source there so e.g. -fno-strict-aliasing or -fwrapv isn't needed) so possibly a RA issue.
