[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