[Bug target/56864] [4.9 regression] FAIL: gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c scan-tree-dump-times vect "vectorized 1 loops" 0

["rguenth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56864

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

--- Comment #14 from Richard Biener <rguenth at gcc dot gnu.org> ---
The difference is:

-/home/andreas/src/gcc/gcc/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c:21:
note: Setting misalignment to -1.
-/home/andreas/src/gcc/gcc/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c:21:
note: Alignment of access forced using peeling.
-/home/andreas/src/gcc/gcc/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c:21:
note: Peeling for alignment will be applied.
-/home/andreas/src/gcc/gcc/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c:21:
note: Vectorizing an unaligned access.
+/home/andreas/src/gcc/gcc/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c:21:
note: vect_model_store_cost: unsupported access.
+/home/andreas/src/gcc/gcc/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c:21:
note: vect_get_data_access_cost: inside_cost = 1000, outside_cost = 0.
+/home/andreas/src/gcc/gcc/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c:21:
note: vect_model_load_cost: aligned.
+/home/andreas/src/gcc/gcc/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c:21:
note: vect_get_data_access_cost: inside_cost = 1001, outside_cost = 0.
+/home/andreas/src/gcc/gcc/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c:21:
note: Alignment of access forced using versioning.
+/home/andreas/src/gcc/gcc/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c:21:
note: Versioning for alignment will be applied.

so we decide to version for alignment instead of peeling for alignment
and decide that that's profitable (the load is aligned already, the
store is, at runtime at least).

I've seen in the past that the outcome of the peeling vs. versioning
decision depends on the order of DRs ... that is, the algorithm is
not stable and clearly doesn't find an optimal solution.  One would need to
single-step through vect_enhance_data_refs_alignment for both revisions
to eventually figure out the underlying issue.

I would be willing to do that with a cross if somebody can provide
preprocessed source and configure args.