This is the mail archive of the
mailing list for the GCC project.
Re: RFC: Handle conditional expression in sccvn/fre/pre
- From: "Bin.Cheng" <amker dot cheng at gmail dot com>
- To: Richard Guenther <richard dot guenther at gmail dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Thu, 1 Mar 2012 22:45:22 +0800
- 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.101.141.1 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>
>> 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:
if (y_3(D) < 1.0e+1)
goto <bb 8>;
goto <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?