Re: Fold some equal to and not equal to patterns in match.pd

[Jeff Law <law at redhat dot com>]

On 07/21/2015 06:40 PM, Andrew Pinski wrote:
> On Tue, Jul 21, 2015 at 12:16 PM, Richard Biener
> <richard.guenther@gmail.com> wrote:
> > On July 21, 2015 11:38:31 AM GMT+02:00, Jakub Jelinek <jakub@redhat.com> wrote:
> > > On Tue, Jul 21, 2015 at 09:15:31AM +0000, Hurugalawadi, Naveen wrote:
> > > > Please find attached the patch which performs following patterns
> > > folding
> > > > in match.pd:-
> > > >
> > > > a ==/!= a p+ b to b ==/!= 0.
> > > > a << N ==/!= 0 to a&(-1>>N) ==/!= 0.
> > >
> > > Not sure about this second one.  Why do you think it is generally
> > > beneficial?  On many targets, shifts are as fast as bitwise and, and
> > > -1>>N could be e.g. significantly more expensive constant (say require
> > > 3 instructions to construct).
> >
> > And may set flags while shift not? Of course we do a very poor job of representing this kind of stuff on gimple.
>
> The biggest question now becomes which way is the canonical form for
> gimple and we can decide to optimize it on the RTL level (combine)
> instead if it produces better code in those cases.
> Note on AARCH64, producing x&(-1>>N) has no cost difference from a<<N
> so we would like to do it there.  Also in this case producing flags is
> useful.
Funny I was having a discussion with Kai about this class of problems 
yesterday.

It seems to me in these kind of cases that selection of the canonical 
form should be driven by factors outside of which is better for a 
particular target.  ie, which is simpler

Instead we should be looking at the gimple->rtl expansion phase to 
expand using a form that is better for a particluar target.

[And yes, I think I've violated this new guiding principle in the past]

Given the (a << n) EQ/NE form, can we reasonably detect this in the 
gimple->expansion phase and emit code as if we had the alternate form 
for targets such as aarch64?

jeff