https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95962
Tamar Christina <tnfchris at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Last reconfirmed| |2021-08-12 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC| |tnfchris at gcc dot gnu.org --- Comment #1 from Tamar Christina <tnfchris at gcc dot gnu.org> --- We generate the correct code at -O3 but not -O2. At -O3 we generate foo: adrp x0, .LC0 sub sp, sp, #16 ldr q0, [x0, #:lo12:.LC0] add sp, sp, 16 ret where the problem seems to be at at -O2 store merging has broken up the construction of `array` into two separate memory accesses: MEM <unsigned long> [(int *)&array] = 4294967296; MEM <unsigned long> [(int *)&array + 8B] = 12884901890; whereas at -O3 we still have a single assignment: MEM <vector(4) int> [(int *)&array] = { 0, 1, 2, 3 }; I'm not sure even if we made these loads gimple level if that would help. we'd still have the explicit MEMs created by store merging. Perhaps we should just make store-merging allow TImode merges and split them in the backend if needed.