Thanks Richard, On Mon, Jan 2, 2012 at 8:33 PM, Richard Guenther <richard.guent...@gmail.com> wrote: > > 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. Here changing GIMPLE_COND to no longer embed the comparison, do you mean this only in fre/pre passes or in common? If only in fre/pre passes, when and how these changed GIMPLE_COND be changed back to normal ones? If in common, won't this affects passes working on GIMPLE_COND, like tree-ssa-forwprop.c?
> > 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. Will you try to handle the reversion comparison case as mentioned in my previous message? I guess this needs both sccvn and fre/pre's work. It would be great to hear your thoughts on this. Thanks -- Best Regards.
