Re: [PATCH v3] EXPR: Emit an truncate if 31+ bits polluted for SImode

[Jeff Law <jeffreyalaw@gmail.com>]

On 12/23/23 17:49, Roger Sayle wrote:
> 
> 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.
What's exceedingly weird is T_N_T_M_P (DImode, SImode) isn't actually a 
truncation!  The output precision is first, the input precision is 
second.  The docs explicitly state the output precision should be 
smaller than the input precision (which makes sense for truncation).

That's where I'd start with trying to untangle this mess.



> 
> 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.
It's less than ideal, but we ended up taking a similar approach in the 
RV world.  We actually have a subset of 32bit instructions in rv64, 
including a 32bit add.

The semantics are that it's a (sign_extend:DI (plus:SI (op1) (op2)))

Modeling it that way was actually critical in eliminating redundant sign 
extensions.

But regardless, it looks like there's something weird going on in the 
MIPS port.

jeff