So would something like

(simplify
 (rshift (nop_convert? (lshift @0 INTEGER_CST@1)) @@1)
 (with { tree stype = build_nonstandard_integer_type (1, 0); }
 (if (INTEGRAL_TYPE_P (type)
      && !TYPE_UNSIGNED (type)
      && wi::eq_p (wi::to_wide (@1), element_precision (type) - 1))
  (convert (convert:stype @0)))))

work?

Drew

On Mon, Jul 24, 2023 at 3:16 AM Richard Biener <richard.guenther@gmail.com>
wrote:

> 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
>
>