Re: [PATCH] match.pd: Implement missed optimization (x << c) >> c -> -(x & 1) [PR101955]

[Richard Biener <richard.guenther@gmail.com>]

On Sat, Jul 22, 2023 at 8:09 AM Jeff Law via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
>
>
>
> On 7/21/23 11:27, Andrew Pinski via Gcc-patches wrote:
> > On Fri, Jul 21, 2023 at 8:09 AM Drew Ross via Gcc-patches
> > <gcc-patches@gcc.gnu.org> wrote:
> >>
> >> Simplifies (x << c) >> c where x is a signed integral type of
> >> width >= int and c = precision(type) - 1 into -(x & 1). Tested successfully
> >> on x86_64 and x86 targets.
> >
> > Thinking about this some more, I think this should be handled in
> > expand rather than on the gimple level.
> > It is very much related to PR 110717 even. We are basically truncating
> > to a signed one bit integer and then sign extending that across the
> > whole code.
> But why defer it to expand?  This idiom is going to generate a -1,0
> result which is definitely interesting from a further simplification
> standpoint.

It's not 'simpler' so it would be a canonicalization.  We talked about
providing a SEXT_EXPR at some point (sign-extend from constant bit N).

Another canonicalization to existing ops would be

 (convert (convert:sbool @0))

where sbool is a 1-bit precision signed type.  I think that's a better
canonicalization
than -(x & 1)?  For zero-extensions we canonicalize such a conversion sequence
to x & const-mask.  For sign-extensions there's no single operation
representation.

Richard.

>
> Jeff