> There's a PR in Bugzilla around this representational issue on MIPS, but I can't find > it straight away.
Found it. It's PR rtl-optimization/104914, where we've already discussed this in comments #15 and #16. > -----Original Message----- > From: Roger Sayle <ro...@nextmovesoftware.com> > Sent: 24 December 2023 00:50 > To: 'gcc-patches@gcc.gnu.org' <gcc-patches@gcc.gnu.org>; 'YunQiang Su' > <s...@gcc.gnu.org> > Cc: 'Jeff Law' <jeffreya...@gmail.com> > Subject: Re: [PATCH v3] EXPR: Emit an truncate if 31+ bits polluted for SImode > > > 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 > --
