This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Conditional negation elimination in tree-ssa-phiopt.c
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: Richard Earnshaw <rearnsha at arm dot com>, Kyrill Tkachov <kyrylo dot tkachov at arm dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Thu, 28 Aug 2014 10:52:55 +0200
- 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> <53FE5806 dot 5010103 at redhat dot com>
On Thu, Aug 28, 2014 at 12:13 AM, Jeff Law <law@redhat.com> wrote:
> On 08/13/14 08:57, 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.
>
> Can't argue with that :-)
>
>
>>
>> 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.
>
> So the big question in my mind is what form do we want through the gimple
> optimizers (COND_EXPR or branchless) and given the chosen form, can we see a
> complex-enough expression at expansion time to realize it's just conditional
> negation and DTRT based on what capabilities the target has?
>
> If keeping the COND_EXPR form allows us to make good decisions at expansion
> time, I'm not opposed to pulling out those bits from phi-opt and making the
> transformation conditional on target attributes during expansion.
I'd do it the other way around (as the phiopt transform is required for
vectorization where vector form may have totally different target
capabilities).
Like for widening multiplication and FMA do target dependent pattern
matching right before RTL expansion (in the widen-mult pass). In this
place you don't need to worry about restrictions given by TER
(no multiple uses, no loads, no crossing BB boundaries, etc.).
Add internal functions for this kind of complex operations (or
do a sequence of stmts that expand can handle, breaking multi-use
chains to get TER doing its job). And guard all this with
optab queries or (yet to implement) can-expand-internal function queries.
Richard.
>
>
> jeff