https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68681
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed| |2015-12-04
Component|tree-optimization |testsuite
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Target Milestone|--- |6.0
Summary|testcase |[6 Regression] testcase
|gcc.dg/vect/pr45752.c fails |gcc.dg/vect/pr45752.c fails
|on AArch64 |on AArch64
Ever confirmed|0 |1
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Huh. It somehow arrives at
gcc/testsuite/gcc.dg/vect/pr45752.c:45:3: note: Load permutation 4 4 4 4 4 0 0
0 3 3 1 1 1 2 2 3 3 3 0 0 2 2 2 1 1
instead of the desired
Load permutation 2 2 2 2 2 3 3 3 3 3 0 0 0 0 0 1 1 1 1 1 4 4 4 4 4
hmm, it's probably a bit of luck which association you get for the addition
chain. tree-reasssoc-width may play a role here - yep, with --param
tree-reassoc-width=2 it fails on x86_64 as well.
This is a missed optimization opportunity - shuffling the SLP tree (where
possible) to make load permutations supported.
In this case we can also amend the testcase to use --param tree-reassoc-width=1
