https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
Richard Earnshaw <rearnsha at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed|2022-07-04 00:00:00 |2022-07-22
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #32 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
So the problem is in postreload.
After register allocation we have (rewritten to make the short insns describe
what's happening):
r5=sp+0xb4
r7=sp+0x64
r4=sp+0xa4
r6=sp+0xa4
102: r0:TI=[sp:SI + 0x84] // Set 5
103: [r4:SI] = r0:TI // Set 5
106: r0:TI=[r4:SI] // Set 0 (memcpy)
107: [r5:SI] = r0:TI // Set 0
110: r0:TI = [r5:SI] // Set 2
111: [r8:SI] = r0:TI // Set 2
114: r0:TI = [r8:SI] // Set 2
115: [lr:SI] = r0:TI // Set 2
118: r0:TI = [lr:SI] // Set 2
119: [r7:SI] = r0:TI // Set 2
122: r0:TI = [r7:SI] // Set 2
123: [r5:SI] = r0:TI // Set 2
126: r0:TI = [r5:SI] // Set 2
127: [SP:SI+0x14] = r0:TI // Set 2
130: r0:TI = [sp:SI+0x14] // Set 2
131: [r4:SI] = r0:TI // Set 2
143: s14:SF=[r6:SI] // Set 1
Where alias set 1 is for float, alias set 2 is for v<float> and alias set 5 is
for v<int>. Alias sets 1 and 2 conflict, but alias set 5 does not.
Posreload removes all the loads except the first and finally removes the store
at insn 131, because value-wise it replicates the store at insn 103. But that
means that the alias dance through the memcpy is lost and so the compiler feels
it is now free (during sched2) to move insn 143 before insn 103.
