https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102949
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Hm, I tried --target=sparcv8-sun-solaris2.11 but that seems to fail to
reproduce any vectorization with -O2 -ftree-vectorize. If I add -mvis I get
something
that could resemble the code you quote:
main1:
save %sp, -104, %sp
cmp %i0, 0
ble,pn %icc, .LL6
mov 30, %g1
sethi %hi(.LLC0), %g3
sethi %hi(uc), %g1
sll %i0, 4, %i0
or %g1, %lo(uc), %g1
sethi %hi(ub), %g2
ldd [%g3+%lo(.LLC0)], %f12
or %g2, %lo(ub), %g2
sethi %hi(.LLC1), %g3
add %i0, %g1, %i0
ldd [%g3+%lo(.LLC1)], %f14
.LL3:
ldd [%g1], %f18
ldd [%g1+8], %f16
ldd [%g2], %f10
ldd [%g2+8], %f8
fpsub32 %f10, %f18, %f10
fpsub32 %f8, %f16, %f8
add %g1, 16, %g1
fpadd32 %f14, %f10, %f14
fpadd32 %f12, %f8, %f12
cmp %i0, %g1
bne,pt %icc, .LL3
add %g2, 16, %g2
here it should be that %g1 is '&uc[0]' initially and maintain alignment.
But somehow we end up with:
.section ".data"
.align 4
.type uc, #object
.size uc, 64
uc:
.long 0
.long 1
.long 2
.long 3
so 'uc' is not properly aligned even though the vectorizer thinks it forces
that. And the rev in question likely caused that to misbehave.
