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
