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