Created attachment 35128 [details] .vect dump of failed test. With gcc 5, the costmodel-vect-31a.c test fails the following assertion: gcc.log:FAIL: gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c scan-tree-dump-times vect "vectorization not profitable" 1 The .vect dump shows vectorization failed (as the test assertion expects) but due to unsupported alignment rather than due to vectorization not being profitable. costmodel-vect-31a.c:27:3: note: Analyze phi: ivtmp_1 = PHI <ivtmp_12(4), 16(2)> costmodel-vect-31a.c:27:3: note: vect_model_store_cost: aligned. costmodel-vect-31a.c:27:3: note: vect_get_data_access_cost: inside_cost = 1, outside_cost = 0. costmodel-vect-31a.c:27:3: note: not vectorized: unsupported unaligned store.tmp.b[i_15] costmodel-vect-31a.c:27:3: note: bad data alignment. costmodel-vect-31a.c:21:5: note: vectorized 0 loops in function.
It's not clear to me if this should be considered a regression. The test passes with 4.9.2, but neither it nor 5.0 vectorizes the loop. The difference and the cause of the test failure appears to be in that 4.9.2 applies loop peeling to align the access but in the end also decides not to vectorize because doing so would not match the profitability criteria, while 5.0 doesn't get that far because it doesn't peel the loop so it gives up earlier (and for a different reason). Here's the relevant portion of the .vect dump with 4.9.2: costmodel-vect-31a.c:27:3: note: === vect_analyze_data_refs_alignment === costmodel-vect-31a.c:27:3: note: vect_compute_data_ref_alignment: costmodel-vect-31a.c:27:3: note: force alignment of tmp.b[i_15] costmodel-vect-31a.c:27:3: note: misalign = 1 bytes of ref tmp.b[i_15] costmodel-vect-31a.c:27:3: note: === vect_prune_runtime_alias_test_list === costmodel-vect-31a.c:27:3: note: === vect_enhance_data_refs_alignment === costmodel-vect-31a.c:27:3: note: data size =1. misalignment = 1. costmodel-vect-31a.c:27:3: note: vect_can_advance_ivs_p: costmodel-vect-31a.c:27:3: note: Analyze phi: i_15 = PHI <i_6(4), 0(2)> costmodel-vect-31a.c:27:3: note: Analyze phi: .MEM_17 = PHI <.MEM_5(4), .MEM_4(D)(2)> costmodel-vect-31a.c:27:3: note: virtual phi. skip. costmodel-vect-31a.c:27:3: note: Analyze phi: ivtmp_1 = PHI <ivtmp_12(4), 16(2)> costmodel-vect-31a.c:27:3: note: vect_model_store_cost: aligned. costmodel-vect-31a.c:27:3: note: vect_get_data_access_cost: inside_cost = 1, outside_cost = 0. costmodel-vect-31a.c:27:3: note: Try peeling by 15 costmodel-vect-31a.c:27:3: note: Alignment of access forced using peeling. costmodel-vect-31a.c:27:3: note: Peeling for alignment will be applied.
Peeling is certainly not profitable as with just 32 char elements in tmp.b and then just iterating over the first 16 there will be no vectorized iteration left if we peel at least one iteration (assuming v16qi vectors). Possibly 4.9 catched this only with the cost model (for targets that support unaligned stores aligned ones may be still better but of course in this case peeling for alignment should be forcefully disabled as it doesn't make sense and just makes us not consider using an unaligned store). Thus, testsuite issue I think.
The test still fails with the latest trunk (6.0) and 5.4 in the latest powerpc64le results reported on gcc-testresults: https://gcc.gnu.org/ml/gcc-testresults/2016-01/msg01830.html https://gcc.gnu.org/ml/gcc-testresults/2016-01/msg01847.html
I will take a look at this relatively soon. Probably just a testsuite issue as Richard surmises.
For GCC 6, this is just a testcase error. The failing assertion requires this clause now that we can vectorize the loop using misaligned loads/stores: { target { ! vect_hw_misalign } } I'll get that fixed shortly, then see what's up on 4.9 and 5.
Author: wschmidt Date: Sat Jan 30 01:18:43 2016 New Revision: 233006 URL: https://gcc.gnu.org/viewcvs?rev=233006&root=gcc&view=rev Log: 2016-01-29 Bill Schmidt <wschmidt@linux.vnet.ibm.com> PR target/65546 * gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c: Correct condition being checked, and disable it when the target supports misaligned loads and stores. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c
Author: wschmidt Date: Sat Jan 30 01:20:27 2016 New Revision: 233007 URL: https://gcc.gnu.org/viewcvs?rev=233007&root=gcc&view=rev Log: 2016-01-29 Bill Schmidt <wschmidt@linux.vnet.ibm.com> PR target/65546 * gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c: Correct condition being checked, and disable it when the target supports misaligned loads and stores. Modified: branches/gcc-5-branch/gcc/testsuite/ChangeLog branches/gcc-5-branch/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c
Fixed in 5 and 6. Test case had resolved in 4.9 since this bug was opened, so work is complete.