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 <[email protected]>
wrote:
> On Sat, Jul 22, 2023 at 8:09 AM Jeff Law via Gcc-patches
> <[email protected]> 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
> > > <[email protected]> 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
>
>
