Between 20210917 (48b3caffcacc99adf72ba1be189a7d9ebc4190be) and 20210918 (e9d8fcabd032b873bf3fe14ae8afd8970827c0cb), 3 vectorization tests regressed on 32-bit Solaris/SPARC and Darwin/PPC: FAIL: gcc.dg/vect/slp-reduc-1.c -flto -ffat-lto-objects execution test FAIL: gcc.dg/vect/slp-reduc-1.c execution test FAIL: gcc.dg/vect/slp-reduc-2.c -flto -ffat-lto-objects execution test FAIL: gcc.dg/vect/slp-reduc-2.c execution test FAIL: gcc.dg/vect/slp-reduc-7.c -flto -ffat-lto-objects execution test FAIL: gcc.dg/vect/slp-reduc-7.c execution test E.g. slp-reduc-1.c: Thread 2 received signal SIGBUS, Bus error. [Switching to Thread 1 (LWP 1)] 0x00010db8 in main1 () 1: x/i $pc => 0x10db8 <main1+56>: ldd [ %g1 ], %f18 (gdb) where #0 0x00010db8 in main1 () #1 0x00010ea4 in main () (gdb) p/x $g1 $1 = 0x2113c The source address isn't properly aligned.
Surely mine, in the range of revs the relevant one would be commit 4703182a06b831a9f47a5f8198e86042cadd938d Author: Richard Biener <rguenther@suse.de> Date: Fri Sep 17 12:48:09 2021 +0200 Revert no longer needed fix for PR95539 The workaround is no longer necessary since we maintain alignment info on the DR group leader only. 2021-09-17 Richard Biener <rguenther@suse.de> * tree-vect-stmts.c (vectorizable_load): Do not frob stmt_info for SLP.
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.
> --- 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: sparcv8-sun-solaris2.11 creates a SPARC V8 default configuration, while the regular sparc-sun-solaris2.11 is SPARC V8+, i.e. SPARC with V9 extensions (which includes -mvis).
> 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: Do you mean sparc-sun-solaris2.11 I presume? V8 is the 32-bit architecture of the 90's, everything is V9 nowadays (but sparcv9-*-* is the 64-bit compiler). But yes, in any case, -mvis is indeed always required to enable vectorization on the SPARC V9. > 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. Possibly too low BIGGEST_ALIGNMENT in 32-bit mode?
(In reply to Eric Botcazou from comment #4) > > 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: > > Do you mean sparc-sun-solaris2.11 I presume? V8 is the 32-bit architecture > of the 90's, everything is V9 nowadays (but sparcv9-*-* is the 64-bit > compiler). > But yes, in any case, -mvis is indeed always required to enable > vectorization on the SPARC V9. > > > 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. > > Possibly too low BIGGEST_ALIGNMENT in 32-bit mode? For the default to work, yes - but I'm testing a patch fixing the vectorizer which attemts to override DECL_ALIGN but fails because of a mistake in the mentioned revision.
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>: https://gcc.gnu.org/g:eed248bb8cc3091e8a9b2f73138c691396752438 commit r12-4763-geed248bb8cc3091e8a9b2f73138c691396752438 Author: Richard Biener <rguenther@suse.de> Date: Thu Oct 28 10:07:40 2021 +0200 tree-optimization/102949 - fix base object alignment This fixes fallout of g:4703182a06b831a9 where we now silently fail to force alignment of a base object. The fix is to look at the dr_info of the group leader to be consistent with alignment analysis. 2021-10-28 Richard Biener <rguenther@suse.de> PR tree-optimization/102949 * tree-vect-stmts.c (ensure_base_align): Look at the dr_info of a group leader and assert we are looking at one with analyzed alignment.
Fixed (by inspecting assembly).
> --- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> --- > Fixed (by inspecting assembly). Indeed: the execution tests PASS again. Thanks.