On Mon, Jan 2, 2012 at 12:37 PM, Amker.Cheng <amker.ch...@gmail.com> wrote:
> Hi,
> Since SCCVN operates on SSA graph instead of the control flow graph
> for the sake of efficiency,
> it does not handle or value number the conditional expression of
> GIMPLE_COND statement.
> As a result, FRE/PRE does not simplify conditional expression, as
> reported in bug 30997.
>
> Since it would be complicate and difficult to process conditional
> expression in currently SCCVN
> algorithm, how about following method?
>
> STEP1  Before starting FRE/PRE, we can factor out the conditional
> expression, like change following
> codes:
> --------------------------------
> if (cond_expr)
>  goto lable_a
> else
>  goto label_b
>
> into codes:
> --------------------------------
> tmp = cond_expr
> if (tmp == 1)
>  goto label_a
> else
>  goto label_b
>
> STEP2  Let SCCVN/FRE/PRE do its job on value numbering cond_expr and
> redundancy elimination;
> STEP3  After FRE/PRE, for those "tmp=cond_expr" not used in any
> redundancy elimination,
> we can forward it to the corresponding GIMPLE_COND statement, just
> like tree-ssa-forwprop.c.
>
> In this way, the conditional expression will be handled as other
> expressions and no
> redundant assignment generated.
> Most important,this does not affect the current implementation of 
> SCCVN/FRE/PRE.
>
> The only problem is the method cannot work on reversion of conditional
> expression.
> For example:
> --------------------------------
> x = a > 2;
> if (a<=2)
>  goto label_a
> else
>  goto lable_b
> could be optimized as:
> --------------------------------
> x = a > 2
> if (x == 0)
>  goto label_a
> else
>  goto label_b
> I have worked a draft patch to do the work and would like to hear your
> comments on this.

I've previously worked on changing GIMPLE_COND to no longer embed
the comparison but carry a predicate SSA_NAME only (this is effectively
what you do as pre-processing before SCCVN).  It had some non-trivial
fallout (for example PRE get's quite confused and ends up separating
conditionals and jumps too far ...) so I didn't finish it.

A subset of all cases can be catched by simply looking up the
N-ary at eliminate () time and re-writing the GIMPLE_COND to use
the predicate - which might not actually be beneficial (but forwprop
will undo not beneficial cases - hopefully).

In the end I'd rather go the way changing the GIMPLE IL to not
embed the comparison in the GIMPLE_COND - that reduces
the amount of redundant way we can express the same thing.

Richard.

> Thanks very much.
> --
> Best Regards.

Reply via email to