This is the mail archive of the
mailing list for the GCC project.
Re: Conditional negation elimination in tree-ssa-phiopt.c
- From: pinskia at gmail dot com
- To: Kyrill Tkachov <kyrylo dot tkachov at arm dot com>
- Cc: Segher Boessenkool <segher at kernel dot crashing dot org>, Richard Earnshaw <Richard dot Earnshaw at arm dot com>, Jeff Law <law at redhat dot com>, Richard Biener <richard dot guenther at gmail dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Thu, 14 Aug 2014 01:57:34 -0700
- Subject: Re: Conditional negation elimination in tree-ssa-phiopt.c
- Authentication-results: sourceware.org; auth=none
- References: <53E8C81B dot 1070303 at arm dot com> <53E91FD8 dot 2000005 at redhat dot com> <CAFiYyc0fk5GybcAZRujABGAssB5udHVfAabpH=pbZVi2N2HQyg at mail dot gmail dot com> <53E9ED14 dot 2080405 at arm dot com> <53EA2338 dot 7010004 at redhat dot com> <53EA2EAA dot 9060402 at arm dot com> <53EA2FD2 dot 3040700 at arm dot com> <53EA48FC dot 3090907 at arm dot com> <53EB7CDB dot 4030806 at arm dot com> <20140813173226 dot GA13178 at gate dot crashing dot org> <53EC7734 dot 4090705 at arm dot com>
> On Aug 14, 2014, at 1:45 AM, Kyrill Tkachov <email@example.com> wrote:
>> On 13/08/14 18:32, Segher Boessenkool wrote:
>>> On Wed, Aug 13, 2014 at 03:57:31PM +0100, Richard Earnshaw wrote:
>>> The problem with the frankenmonster patterns is that they tend to
>>> proliferate into the machine description, and before you know where you
>>> are the back-end is full of them.
>>> Furthermore, they are very sensitive to the greedy first-match nature of
>>> combine: a better, later, combination is missed because a less good,
>>> earlier, optimization matched. If the first insn in the sequence is
>>> merged into an earlier instruction then you can end up with a junk
>>> sequence that completely fails to simplify. That ends up with
>>> super-frankenmonster patterns to deal with all the subcases and the
>>> problems grow exponentially from there.
>> Right. Of course, combine should be fixed, yadda yadda.
>>> I really do think that the best solution would be to try and catch this
>>> during expand if possible and generate the right pattern from the start;
>>> then you don't risk combine failing to come to the rescue after several
>>> intermediate transformations have taken place.
>> I think ssa-phiopt should simply not do this obfuscation at all. Without
>> it, RTL ifcvt picks it up just fine on targets with conditional assignment
>> instructions. I agree on targets without expand should do a better job
>> (also for more generic conditional assignment).
> That particular transformation was added to tree-ssa-phiopt.c for PR 45685, the problem it was trying to solve was a missed vectorisation opportunity and transforming it made it into straightline code that was more amenable to vectorisation, that's why I'm somewhat reluctant to completely disable it.
Well if we used COND_EXPR instead for both vectorizer and this case and have Expr.c do the expansion, we solve both issues without any target specific issue on the gimple level :).
I might submit a few patches to do something this next year. I have some patches right now but due to internal timing I don't have time to submit them upstream just yet. I developed them for our MIPS product but it carries nicely over to our aarch64 processor too.
> Hmm... I noticed in the midend we guard some optimisations on HAVE_conditional_move. Maybe we can guard this one on something like !HAVE_conditional_negation ?
>> Instruction selection belongs in RTL land.