https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70011
Bill Schmidt <wschmidt at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2016-02-29
Ever confirmed|0 |1
--- Comment #4 from Bill Schmidt <wschmidt at gcc dot gnu.org> ---
Looks like another case where the test case hasn't kept up with changes to the
vectorizer and the Power hardware. In GCC 5, we have an unaligned access and
choose to peel for alignment. In GCC 6, we recognize that we have an unaligned
access but that it is supported by hardware, and we analyze the loop without
peeling. In GCC 5, the peeling is unprofitable (number of iterations is 7, and
we need 11 to make it profitable in light of the extra setup code). In GCC 6,
the cost model says we only need 5 iterations to make it profitable, so the
loop is vectorized.
I think that earlier in GCC 6 we still didn't vectorize this. It looks like we
now produce better code because vect_recog_mult_pattern kicks in where it
didn't before.
I think this probably would fail the same way on BE on a POWER8 system. Bill
Seurer, can you confirm that the BE system you tested on was a POWER7? The
alignment issue should be due to P8 hardware improvements, not anything
endian-related.
If that's the case, then I think we just need to adjust this test case to skip
the failing predicate when hardware alignment is supported, similar to the big
set of tests I changed last year for the same reason.
