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.