[Bug target/65660] [5 Regression] 252.eon regression on bdver2 with -Ofast

rguenth at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Tue Apr 7 07:46:00 GMT 2015


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

           What    |Removed                     |Added
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-04-07
     Ever confirmed|0                           |1

--- Comment #13 from Richard Biener <rguenth at gcc dot gnu.org> ---
Indeed g++.dg/vect/slp-pr56812.cc FAILs with -march=bdver2 because we loop
vectorize the testcase (not wrong, but wrong is that we vectorize it by
applying peeling for alignment).

On the tester I tested a "simple"

Index: gcc/tree-vect-data-refs.c
--- gcc/tree-vect-data-refs.c   (revision 221808)
+++ gcc/tree-vect-data-refs.c   (working copy)
@@ -1548,7 +1548,7 @@ vect_enhance_data_refs_alignment (loop_v
       && all_misalignments_unknown
       && LOOP_VINFO_NITERS_KNOWN_P (loop_vinfo)
       && (LOOP_VINFO_INT_NITERS (loop_vinfo)
-         < 2 * (unsigned) LOOP_VINFO_VECT_FACTOR (loop_vinfo) - 1))
+         < 3 * (unsigned) LOOP_VINFO_VECT_FACTOR (loop_vinfo) - 1))
     do_peeling = false;

   if (do_peeling

but at this stage this will have too much testsuite fallout (in archs I
did not test).

The "real" fix is to apply similar cost considerations as the final cost model
does when deciding peeling for alignment (which is hardly profitable on most

A good fix restricted to bdver2 is to increase the suspiciously low cost of
taken/not taken branches.  I am going to propose a patch doing that.

More information about the Gcc-bugs mailing list