Hi YunQiang (and Jeff),
> MIPS claims TRULY_NOOP_TRUNCATION_MODES_P (DImode, SImode)) == true > based on that the hard register is always sign-extended, but here > the hard register is polluted by zero_extract. I suspect that the bug here is that the MIPS backend shouldn't be returning true for TRULY_NOOP_TRUNCATION_MODES_P (DImode, SImode). It's true that the backend stores SImode values in DImode registers by sign extending them, but this doesn't mean that any DImode pseudo register can be truncated to an SImode pseudo just by SUBREG/register naming. As you point out, if the high bits of a DImode value are random, truncation isn't a no-op, and requires an explicit sign-extension instruction. There's a PR in Bugzilla around this representational issue on MIPS, but I can't find it straight away. Out of curiosity, how badly affected is the testsuite if mips.cc's mips_truly_noop_truncation (poly_uint64 outprec, poly_uint64 inprec) is changed to just return !TARGET_64BIT ? I agree with Jeff there's an invariant that isn't correctly being modelled by the MIPS machine description. A machine description probably shouldn't define an addsi3 pattern if what it actually supports is (sign_extend:DI (truncate:SI (plus:DI (reg:DI x) (reg:DI y)))) Trying to model this as SImode addition plus a SUBREG_PROMOTED flag is less than ideal. Just my thoughts. I'm curious what other folks think. Cheers, Roger --
