[Bug rtl-optimization/104914] [MIPS] wrong comparison with scrabbled int value

["syq at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914

--- Comment #16 from YunQiang Su <syq at gcc dot gnu.org> ---
(In reply to Roger Sayle from comment #15)
> Is MIPS64 actually a TRULY_NOOP_TRUNCATION_TARGET?  If SImode is implicitly
> assumed to be (sign?) extended, then an arbitrary DImode value/register
> can't be used as an SImode value without appropriately setting/clearing the
> upper bits.
> i.e. thus this integer truncation isn't a no-op.
> 

in gcc/config/mips/mips.cc, there are lines:

static bool
mips_truly_noop_truncation (poly_uint64 outprec, poly_uint64 inprec)
{
  return !TARGET_64BIT || inprec <= 32 || outprec > 32;
}


So for mips_truly_noop_truncation(64, 32), it is true, aka we can convert
32bit value to 64bit value without any insn.

This setting is based on that most (if not all) word (32bit) operation insns
are all sign-extend.

For example, when we run these instructions on a MIPS64 CPU
      li $a1, 0x7fffffff
      add $a3, $a1, $a1
The result of $a3 will be:
      0xffffffff fffffffe

And for theses instructions:
      li $a1, 0x7fffffff
      dadd $a3, $a1, $a1  # note, add -> dadd
Then the content of $a3 will be:
     0x00000000 fffffffe


And MIPS has the single instruction for: branch less than zero, for both
MIPS32, MIPS64.

Let me explain example 1:
    if the code is running on a 32bit CPU, the result of $a3 will be
0xfffffffe, which is -2.
    if the code is running on a 64bit CPU, since the result of $a3 will be
sign-extend to 0xffffffff fffffffe,
       it is still -2.

That's how MIPS make 32bit binaries run smoothly on a 64bit CPU 
without any mode switch.

> I suspect that the underlying problem is that the backend is relying on
> implicit invariants, not explicitly represented in the RTL, and then
> surprised when valid RTL transformations don't preserve those
> invariants/assumptions.
> 
> I wonder why the zero_extract followed by sign_extend example mentioned in
> https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626137.html isn't
> already being considered as a try_combine candidate, allowing the backend to
> simply recognize or split it.  I'll investigate.

Thanks.