[Bug c++/69564] [5/6 Regression] lto and/or C++ make scimark2 LU slower

rguenth at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Tue Mar 29 11:19:00 GMT 2016


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

--- Comment #23 from Richard Biener <rguenth at gcc dot gnu.org> ---
So I tried to investigate why prediction doesn't fix this.  In fact with the
following patch I get to a similar level of performance as with not folding
the conditional (notice append_to_statement_list_force which isn't used in
continue genericization which means its predict-expr is thrown away...):

Index: gcc/cp/cp-gimplify.c
===================================================================
--- gcc/cp/cp-gimplify.c        (revision 234453)
+++ gcc/cp/cp-gimplify.c        (working copy)
@@ -237,8 +237,12 @@ genericize_cp_loop (tree *stmt_p, locati
       location_t cloc = EXPR_LOC_OR_LOC (cond, start_locus);
       exit = build1_loc (cloc, GOTO_EXPR, void_type_node,
                         get_bc_label (bc_break));
+      tree pred = build_predict_expr (PRED_LOOP_EXIT, NOT_TAKEN);
+      tree stmt_list = NULL;
+      append_to_statement_list_force (pred, &stmt_list);
+      append_to_statement_list (exit, &stmt_list);
       exit = fold_build3_loc (cloc, COND_EXPR, void_type_node, cond,
-                             build_empty_stmt (cloc), exit);
+                             build_empty_stmt (cloc), stmt_list);
     }

   if (exit && cond_is_first)


Now the question to me is still why we don't predict the loop exit correctly
ourselves (or not as strong as desired for this testcase).  Honza?  The loop
has multiple exits and a non-constant iteration bound which is where
predict_loops () gives up.  So the question is whether the above is a good
idea in general (likewise "fixing" the continue predict hint below).  The
loop in question is

    for (j=0; j<minMN; j++)
    {
... loop ...
        if ( A[jp][j] == 0 )
            return 1;       /* factorization failed because of zero pivot */
... conditional loop ...
... conditional loop nest ...
    }

and we only predict with

              int probability = ((REG_BR_PROB_BASE
                                  - predictor_info [(int)
PRED_LOOP_EXIT].hitrate)
                                 / n_exits);

where n_exits == 2.  But the question is really why basic-block order
or branch inversion makes this kind of difference.  We _do_ predict
the same with the s/fold_//g patch from Patrick.


The following patch "fixes" continue genericization.

Index: gcc/cp/cp-gimplify.c
===================================================================
--- gcc/cp/cp-gimplify.c        (revision 234453)
+++ gcc/cp/cp-gimplify.c        (working copy)
@@ -361,7 +365,7 @@ genericize_continue_stmt (tree *stmt_p)
   tree label = get_bc_label (bc_continue);
   location_t location = EXPR_LOCATION (*stmt_p);
   tree jump = build1_loc (location, GOTO_EXPR, void_type_node, label);
-  append_to_statement_list (pred, &stmt_list);
+  append_to_statement_list_force (pred, &stmt_list);
   append_to_statement_list (jump, &stmt_list);
   *stmt_p = stmt_list;
 }


More information about the Gcc-bugs mailing list