On Thu, Mar 1, 2012 at 3:45 PM, Bin.Cheng <amker.ch...@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.
