[Patch] [Aarch64] PR rtl-optimization/87763 - this patch fixes gcc.target/aarch64/lsl_asr_sbfiz.c

Jeff Law law@redhat.com
Sat Apr 27 15:26:00 GMT 2019

On 4/26/19 5:59 PM, Segher Boessenkool wrote:
> On Fri, Apr 26, 2019 at 11:30:47PM +0100, Richard Earnshaw (lists) wrote:
>> A subreg on a reg is fine (which is what we'd have in this specific
>> case).  It's when the subreg gets left on something else (other than a
>> mem) when the problems start.
> Yeah.  We typically push the subregs as far inward as we can.  I have a
> patch for one case where we explicitly pull a subreg to the left instead,
> and that destroys all of rs6000's insert patterns :-/
Richard, if you go back to Steve's patch and its discussion from Jan
you'll see that the subregs are not just on the register operand, but
also on the sign_extract:

Quoting from Steve's post:

> (set (reg:SI 93)
>     (ashift:SI (subreg:SI (sign_extract:DI (subreg:DI (reg:SI 95) 0)
>                 (const_int 3 [0x3])
>                 (const_int 0 [0])) 0)
>         (const_int 19 [0x13])))
> The subreg's were not there before.  My proposed fix is to add an new
> instruction like *ashiftsi_extv_bfiz but with the subregs.  This fixes
> lsl_asr_sbfiz.c.  Does this seem like the right way to fix this?

To fix this without having the two mode pattern I've proposed or a
pattern which matches the subreg mess above we'd need combine or
simplify-rtx to simplify the above into something like this (From Andrew P):

> Seems to me rather this should have been simplified to just:
>  (set (reg:SI 93)
>      (ashift:SI (sign_extract:SI (reg:SI 95)
>                  (const_int 3 [0x3])
>                  (const_int 0 [0]))
>          (const_int 19 [0x13])))
> Because the two subreg cancel each other out.
> This would be a thing to add to simplify-rtx.c.


More information about the Gcc-patches mailing list