This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: Handle conditional expression in sccvn/fre/pre

On Mon, Jan 2, 2012 at 12:37 PM, Amker.Cheng <> 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.


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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]