>> 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?
--
Best Regards.
