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

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65660

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
With a true fix I get

t.c:3:20: note: Cost model analysis:
  Vector inside of loop cost: 4
  Vector prologue cost: 13
  Vector epilogue cost: 11
  Scalar iteration cost: 4
  Scalar outside cost: 0
  Vector outside cost: 24
  prologue iterations: 2
  epilogue iterations: 2
  Calculated minimum iters for profitability: 7
t.c:3:20: note:   Runtime profitability threshold = 6
t.c:3:20: note:   Static estimate profitability threshold = 6

thus we still vectorize the loop for bdver2.  This is because of an oddity
in its cost model which has

  6,                                    /* scalar_stmt_cost.  */
  4,                                    /* scalar load_cost.  */
  4,                                    /* scalar_store_cost.  */
  6,                                    /* vec_stmt_cost.  */
  0,                                    /* vec_to_scalar_cost.  */
  2,                                    /* scalar_to_vec_cost.  */
  4,                                    /* vec_align_load_cost.  */
  4,                                    /* vec_unalign_load_cost.  */
  4,                                    /* vec_store_cost.  */
  2,                                    /* cond_taken_branch_cost.  */
  1,                                    /* cond_not_taken_branch_cost.  */

and thus the prologue/epilogue is not pessimized enough for the extra
branches (which are very cheap compared to the scalar and vector stmt costs).

I am still testing the patch to avoid the round-off errors and really account
scalar stmts correctly.

I suppose the EON regression should be fixed by instead avoiding the
peeling for alignment with a better idea on cost.