Re: [PATCH] Fix simplify_shift_const_1 once more (PR rtl-optimization/70429)

[Jeff Law <law at redhat dot com>]

On 03/29/2016 11:43 AM, Jakub Jelinek wrote:
> On Tue, Mar 29, 2016 at 11:34:29AM -0600, Jeff Law wrote:
> > > This is a case similar to the LSHIFTRT I've fixed recently.
> > > But, unlike LSHIFTRT, which can be handled by masking at the outer level,
> > > ASHIFTRT would need outer sign extension, so most of the time 2 outer
> > > operations in addition to the kept two inner shifts, which is IMHO very
> > > unlikely to ever be successfully combined on any target nor actually
> > > beneficial.  So this patch just avoids that optimization for ASHIFTRT
> > > if there are different modes.
> > >
> > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> > >
> > > 2016-03-29  Jakub Jelinek  <jakub@redhat.com>
> > >
> > > 	PR rtl-optimization/70429
> > > 	* combine.c (simplify_shift_const_1): For ASHIFTRT don't optimize
> > > 	(cst1 >> count) >> cst2 into (cst1 >> cst2) >> count if
> > > 	mode != result_mode.
> > >
> > > 	* gcc.c-torture/execute/pr70429.c: New test.
> > But isn't the point of this code that cst1 >> cst2 turns into a compile time
> > constant just leaving one runtime shift of the result by count?
>
> But with the mode change then you are changing
> (cst1 >> count) >> cst2
> into
> ((((cst1 >> cst2) >> count) << (bitsz - cst2)) >> (bitsz - cst))
Why can't we sign extend cst1 >> cst2 at compile time and use a ASHIFTRT 
for the >> count shift?   Even if we've got a mode change to deal with, 
we can generate the constant in whatever mode we want.

I must  be missing something here.

jeff