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

[Richard Guenther <richard dot guenther at gmail dot com>]

On Thu, Mar 1, 2012 at 3:45 PM, Bin.Cheng <amker.cheng@gmail.com> wrote:
>>> Second point, as you said, PRE often get confused and moves compare
>>> EXPR far from jump statement. Could we rely on register re-materialize
>>> to handle this, or any other solution?
>>
>> Well, a simple kind of solution would be to preprocess the IL before
>> redundancy elimination and separate the predicate computation from
>> their uses and then as followup combine predicates back (tree forwprop
>> would do that, for example - even for multiple uses). ?The question is
>> what you gain in the end.
>
> I realized there is no merit if compare EXPR is factored only for PRE pass.
>
>>
>>> I would like to learn more about this case, so do you have any opinion on
>>> how this should be fixed for now.
>>
>> The GIMPLE IL should be better here, especially if you consider that
>> we force away predicate computation that may trap for -fnon-call-exceptions
>> already. ?So, simplifying the IL is still the way to go IMHO. ?But as I said
>> above - it's a non-trivial task with possibly much fallout.
>>
> There is another benefit. Currently general compare EXPR is a dead case GCC
> can not handle in conditional const/copy propagation. It can be handled properly
> after rewriting, since GIMPLE_COND only contains a predicate SSA_NAME.
> For example, redundant gimple generated for test case in pr38998:
>
> <bb 2>:
> ?if (y_3(D) < 1.0e+1)
> ? ?goto <bb 8>;
> ?else
> ? ?goto <bb 3>;
>
> <bb 3>:
> ?D.4069_7 = cos (y_3(D));
> ?if (y_3(D) < 1.0e+1)
> ? ?goto <bb 4>;
> ?else
> ? ?goto <bb 5>;
>
> I do think these "non-canonical" compare EXPR might seed other issues.
>
> As for the fallout you mentioned, how about introduce a light-weight pass
> at the very end of middle end to propagate the compare EXPR back to
> GIMPLE_COND if the corresponding predicate SSA_NAME is down-safe
> only because it is used by GIMPLE_COND.
>
> So what do you think?

Well, I'm all for it, but the fallout is in the GIMPLE middle-end pieces.
It's just a lot of work ;)  And I'd rather start forcing the predicate
separation for VEC_COND_EXPRs and COND_EXPRs as they appear
on the RHS of gimple assigns.  That should be simpler and the fallout
should be less.

If you want to do the work I promise to review patches.

Richard.

> --
> Best Regards.