[Bug tree-optimization/84005] [8 regression] gcc.dg/vect/bb-slp-1.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84005 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from rsandifo at gcc dot gnu.org --- Fixed on trunk.
[Bug tree-optimization/84005] [8 regression] gcc.dg/vect/bb-slp-1.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84005 --- Comment #11 from rsandifo at gcc dot gnu.org --- Author: rsandifo Date: Sat Mar 24 10:52:34 2018 New Revision: 258833 URL: https://gcc.gnu.org/viewcvs?rev=258833&root=gcc&view=rev Log: Use SCEV information when aligning for vectorisation (PR 84005) This PR is another regression caused by the removal of the simple_iv check in dr_analyze_innermost for BB analysis. Without splitting out the step, we weren't able to find an underlying object whose alignment could be increased. As with PR81635, I think the simple_iv was only handling one special case of something that ought to be more general. The more general thing here is that if the address can be analysed as a scalar evolution, and if all updates preserve alignment N, it's possible to align the address to N by increasing the alignment of the base object to N. That applies also to outer loops, and to both loop and BB analysis. I wasn't sure where the new functions ought to live, but tree-data-ref.c seemed OK since (a) that already does scev analysis on addresses and (b) you'd want to use dr_analyze_innermost first if you were analysing a reference. 2018-03-24 Richard Sandiford gcc/ PR tree-optimization/84005 * tree-data-ref.h (get_base_for_alignment): Declare. * tree-data-ref.c (get_base_for_alignment_1): New function. (get_base_for_alignment): Likewise. * tree-vect-data-refs.c (vect_compute_data_ref_alignment): Use get_base_for_alignment to find a suitable base object, instead of always using drb->base_address. gcc/testsuite/ PR tree-optimization/84005 * gcc.dg/vect/bb-slp-1.c: Make sure there is no message about failing to force the alignment. Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/bb-slp-1.c trunk/gcc/tree-data-ref.c trunk/gcc/tree-data-ref.h trunk/gcc/tree-vect-data-refs.c
[Bug tree-optimization/84005] [8 regression] gcc.dg/vect/bb-slp-1.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84005 --- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #9 from rsandifo at gcc dot gnu.org gnu.org> --- [...] > Could you try the attached patch? It should restore the ability > to look through steps when trying to align variables. I've regtested the patch on sparc-sun-solaris2.11 (and i386-pc-solaris2.11 for good measure): the bb-slp-*.c failures are gone on sparc, no change on i386. Thanks. Rainer
[Bug tree-optimization/84005] [8 regression] gcc.dg/vect/bb-slp-1.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84005 --- Comment #9 from rsandifo at gcc dot gnu.org --- Created attachment 43673 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43673&action=edit Candidate patch Could you try the attached patch? It should restore the ability to look through steps when trying to align variables. Tested so far on aarch64-linux-gnu.
[Bug tree-optimization/84005] [8 regression] gcc.dg/vect/bb-slp-1.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84005 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org --- Comment #8 from rsandifo at gcc dot gnu.org --- Mine. I think we can handle this in vect_can_force_dr_alignment_p, maybe using SCEV analysis.
[Bug tree-optimization/84005] [8 regression] gcc.dg/vect/bb-slp-1.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84005 --- Comment #7 from Jakub Jelinek --- This is from cross to powerpc64-linux, -maltivec -mvsx -mno-allow-movmisalign -ftree-vectorize -fno-vect-cost-model -fno-common -O2 bb-slp-1.c -nostdinc -fdump-tree-slp-details
[Bug tree-optimization/84005] [8 regression] gcc.dg/vect/bb-slp-1.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84005 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||rsandifo at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- This changed with r249896. Creating dr for *pin_64 analyze_innermost: success. - base_address: &in + base_address: pin_64 offset from base address: 0 constant offset from base address: 0 - step: 32 + step: 0 aligned to: 128 base_object: *pin_64 Creating dr for *pout_65 analyze_innermost: success. - base_address: &out + base_address: pout_65 offset from base address: 0 constant offset from base address: 0 - step: 32 + step: 0 aligned to: 128 base_object: *pout_65 and similarly many times, -bb-slp-1.c:25:7: note: misalign = 0 bytes of ref *pin_64 +bb-slp-1.c:25:7: note: can't force alignment of ref: *pin_64 +bb-slp-1.c:25:7: note: Vectorizing an unaligned access. ... and finally -bb-slp-1.c:15:3: note: basic block vectorized
[Bug tree-optimization/84005] [8 regression] gcc.dg/vect/bb-slp-1.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84005 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #5 from Eric Botcazou --- So either we bump the alignment of the arrays or we selectively XFAIL?
[Bug tree-optimization/84005] [8 regression] gcc.dg/vect/bb-slp-1.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84005 --- Comment #4 from Alexandre Oliva --- I guess this is a case of adding xfails or target requirements to the dg comments, but I'm not sufficiently familiar with the various vector-related pseudo-target names to tell which ones would be right, so I'm leaving this for someone else who does to address.
[Bug tree-optimization/84005] [8 regression] gcc.dg/vect/bb-slp-1.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84005 --- Comment #3 from Alexandre Oliva --- With the current vect alignment computations, we end up using the alignment of the arrays, so on x86_64 it's 256bits (DATA_ALIGNMENT bumps the alignment up) and on ppc64 it's 32bits, no alignment bump. Back on Jul 2, AFAICT we'd miscompute the alignment: dr_analyze_innermost would set up base_iv with the array ptr and the loop increment, and the offset from base, that would have made to offset_iv and from that to DR_ALIGNED_TO, ends up having the constant moved to DR_INIT, and DR_ALIGNED_TO, initialized from a zero offset, ends up as BIGGEST_ALIGNMENT. I don't see that we can proceed to vectorizing the loop if we can't guarantee alignment, so it seems like the so-called regression is actually progress, and it would only have worked at run time by accident. The solution to enable vectorization, AFAICT, is to explicitly specify higher alignment for the arrays in the testcases.
[Bug tree-optimization/84005] [8 regression] gcc.dg/vect/bb-slp-1.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84005 Alexandre Oliva changed: What|Removed |Added CC||aoliva at gcc dot gnu.org --- Comment #2 from Alexandre Oliva --- Yeah, it looks like alignment. On x86_64 -msse2, the new base alignments for pin and pout are 32, whereas on ppc64 -maltivec they're 4, and then it says it can't force the alignment and finally that it doesn't vectorize due to no support for unaligned store and bad alignment in the block. Looking into it...
[Bug tree-optimization/84005] [8 regression] gcc.dg/vect/bb-slp-1.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84005 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-24 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Needs investigation (alignment issue?).
[Bug tree-optimization/84005] [8 regression] gcc.dg/vect/bb-slp-1.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84005 Rainer Orth changed: What|Removed |Added Target Milestone|--- |8.0
