This is the mail archive of the
mailing list for the GCC project.
Re: RFC: Handle conditional expression in sccvn/fre/pre
- From: Richard Guenther <richard dot guenther at gmail dot com>
- To: "Bin.Cheng" <amker dot cheng at gmail dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Thu, 1 Mar 2012 16:22:15 +0100
- Subject: Re: RFC: Handle conditional expression in sccvn/fre/pre
- Authentication-results: mr.google.com; spf=pass (google.com: domain of email@example.com designates 10.42.73.136 as permitted sender) firstname.lastname@example.org; dkim=pass email@example.com
- References: <CAHFci28JadXvP4MGMDfwODsxuJ2-8NK9ZXEgURPGTWYcPfirstname.lastname@example.org> <CAFiYyc3Dp3r=BkYNzQt+tU2BeOXQDgxgevM_rp3nD+_DPRSx4w@mail.gmail.com> <CAHFci29Oe3-cQZ4M40kWrrNsmRZ_OexWrPz+ScJphTGY89BtFQ@mail.gmail.com> <CAFiYyc3yE5ECmz2MFr89CXVhOU9wfKNZYs_GYk-HGTNfsFuxLA@mail.gmail.com> <CAHFci2_JPt1-4EcxDLvG3h_4eqq5fr_qEMswV6-mojmmP6auYA@mail.gmail.com> <CAFiYyc3YxyLim5OLibuoBSshEhOhXyFbLVEHLry=fwmhSBnrpQ@mail.gmail.com> <CAHFci28WKuV3e1Us99-icEuTt6yQ_q7Ak47gf8YR7DBRAq2uTw@mail.gmail.com> <CAFiYyc16jFs-ZYRB67Cue5inRDaRPAsHkDL4YC4frzHRJ8VMwQ@mail.gmail.com> <CAHFci2-J0p5FwNhUvZbS4quDfnfm7OxhA3CAXxK0uwdxncMR7w@mail.gmail.com>
On Thu, Mar 1, 2012 at 3:45 PM, Bin.Cheng <email@example.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>;
> ? ?goto <bb 3>;
> <bb 3>:
> ?D.4069_7 = cos (y_3(D));
> ?if (y_3(D) < 1.0e+1)
> ? ?goto <bb 4>;
> ? ?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.
> Best Regards.