Roger Sayle <ro...@nextmovesoftware.com> 于2023年12月24日周日 08:49写道：
>
>
> 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.
>
Yes, you are right. While in most case, software/compiler carefully,
when work with SI variables, only instructions these instruction are used:
1. the result of this instruction is proper sign-extended,
normally, the instructions from MIPS32.
2. or use LW to load the value: LW also will sign-extend the registers.
> 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 ?
>
It will make some performance regression. Use our new tests as an example
The result will be:
lbu $2,0($4)
SLL # newly added
lbu $3,1($4)
dins $2,$3,8,8
SLL # newly added
lbu $3,2($4)
dins $2,$3,16,8
SLL # newly added
lbu $3,3($4)
dins $2,$3,24,8
sll $2,$2
As my previous patch did, here, in fact if we replace all DINS with INS,
it will just work.
> 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.
>
The addsi3 on MIPS64 is like:
(define_insn "*addsi3_extended"
[(set (match_operand:DI 0 "register_operand" "=d,d")
(sign_extend:DI
(plus:SI (match_operand:SI 1 "register_operand" "d,d")
(match_operand:SI 2 "arith_operand" "d,Q"))))]
"TARGET_64BIT && !TARGET_MIPS16"
"@
addu\t%0,%1,%2
addiu\t%0,%1,%2"
[(set_attr "alu_type" "add")
(set_attr "mode" "SI")])
It expect the source register is in SImode. And in fact in the ISA
documents: the result of ADD/ADDU will be UNPREDICTABLE
if sources is not well sign-extended.
> Just my thoughts. I'm curious what other folks think.
>
> Cheers,
> Roger
> --
>
>
