[PATCH] combine: Convert subreg-of-lshiftrt to zero_extract properly (PR78390)

Dominik Vogt vogt@linux.vnet.ibm.com
Thu Nov 24 14:46:00 GMT 2016


On Thu, Nov 24, 2016 at 03:01:02PM +0100, Michael Matz wrote:
> Hi,
> 
> On Thu, 24 Nov 2016, Dominik Vogt wrote:
> 
> > On s390 (31-Bit) we get two (easily fixable) test regression
> > supposedly because of the original path (+ this fix), and I don't
> > know what to do about it.  Perhaps these point to two situations,
> > where the change from lshiftrt to zero_extract sould not be done?
> 
> The _extract forms are considered to be the canonical ones for backends 
> that support them (I don't know why).  It's just that the canonicalization 
> wasn't applied as often as it could and hence some backends aren't 
> prepared to see it for also trivial cases.
> 
> > 1) (subtests f29 and f31 in s390/risbg-ll-1.c)
> > 
> > An unpatched Gcc would generate this:
> > 
> > --
> > (insn 19 17 20 2 (set (reg:DI 2 %r2 [+-4 ])
> >         (lshiftrt:DI (reg:DI 66 [ v_shl ])
> >             (const_int 32 [0x20])))
> > 
> > (insn 20 19 21 2 (set (reg:SI 3 %r3)
> >         (subreg:SI (reg:DI 66 [ v_shl ]) 4))
> > --
> > 
> > A patched Gcc generates
> > 
> > --
> > (insn 19 17 20 2 (parallel [
> >             (set (reg:DI 2 %r2 [+-4 ])
> >                 (zero_extract:DI (reg:DI 66 [ v_shl ])
> >                     (const_int 32 [0x20])
> >                     (const_int 0 [0])))
> >             (clobber (reg:CC 33 %cc))
> 
> Well, one insn instead of two, seems sensible to me.

That was a copy-and-paste mistake.  Insn 20 does not go away with
the patched Gcc.

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt
IBM Germany



More information about the Gcc-patches mailing list