This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Continue stmt branch prediction
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: "Jan Hubicka" <jh at suse dot cz>
- Cc: gcc-patches at gcc dot gnu dot org, dnovillo at google dot com
- Date: Tue, 18 Mar 2008 23:21:49 -0700
- Subject: Re: Continue stmt branch prediction
- References: <20080209194852.GO1026@kam.mff.cuni.cz>
Hi,
This patch may have caused
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35636
H.J.
On Sat, Feb 9, 2008 at 12:48 PM, Jan Hubicka <jh@suse.cz> wrote:
>
> Hi,
> this patch adds a continue branch predictor that was dropped by introduction of
> gimplifier (that replaced continue statement by goto).
>
> The idea is that continue statements forms a loops that are usually not looping,
> as proper loops are written via the loop construct. On SPECint2000 average loop
> tends to loop 7 times, while average loop constructed via continue loops less
> than once.
>
> The prediction is implemented via high level predictors that used also to predict,
> for example, that explicit goto statements are not taken (this is helping kernel)
> and can be used for other stuff in other languages too.
> I will re-introduce the other predictors by followups later, this patch was
> developed while looking into the gzip regression as predicting continue formed
> loop to loop a lot is one of problems there:
>
> statement
> if (test1 || test2 || test3 || test4)
> continue;
>
> is in mainline handled as 4 nested loops, each predicted to loop roughly 4 times,
> making all the rest of function cold.
>
> Since the patch itself is not solving the regression fully (it makes improvement
> on prelbmk 64bit peak, 920->980, and gzip 64bit, 750->770) but irronically it causes
> regression at -O3 score of gzip 32bit by exposing other problems. So I am holding
> it for 4.4.
>
> The branch prediction bits I can approve myself, but I would welcome comment on
> introducing PREDICT_EXPR. This was discussed while ago on GCC summit. (the
> original patch was done at CFG expansion times, but since we was about to run
> out of tree codes I holded it and then forgot about the issue completely).
>
> Bootstrapped/regtested i686-linux.
>
> Honza
>
> * tree-pretty-print.c: Include predict.h.
> (dump_generic_node): Dump predictor.
> * tree.h (PREDICT_EXPR_OUTCOME, PREDICT_EXPR_PREDICTION): Update.
> * tree-gimple.c (is_gimple_stmt): Add PREDICT_EXPR.
> * gimple-low.c (lower_stmt): Likewise.
> * expr.c (expand_expr_real): Likewise.
> * predict.c (tree_bb_level_predictions): Use PREDICT_EXPRs and remove
> them.
> (build_predict_expr, build_predict_expr): New.
> * predict.h (predictor_name, build_predict_expr): Update.
> * c-typeck.c (c_finish_bc_stmt): Add prediction.
> * gimplify.c (gimplify_expr): Add PREDICT_EXPR.
> * predict.def (PRED_CONTINUE): Update hitrate.
> * tree.def (PREDICT_EXPR): Define.
> * tree-ssa-dce.c (mark_stmt_if_obviously_necessary): Mark PREDICT_EXPR;
> do not handle BIND_EXPR.
> * tree-inline.c (estimate_num_insns_1): PREDICT_EXPR is free.
> * tree-cfg.c (verify_gimple_stmt): PREDICT_EXPR is valid.
> * tree-ssa-operands.c (get_expr_operands): PREDICT_EXPR takes no operands.
>
>