This is the mail archive of the gcc@gcc.gnu.org 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


Thanks Richard,

On Mon, Jan 2, 2012 at 8:33 PM, Richard Guenther
<richard.guenther@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.


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