From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 257523858D35; Thu,  3 Aug 2023 09:34:08 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 257523858D35
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1691055248;
	bh=vpWhGbLPfABOqErjlTsV+eF5D9lC3E25pd9q76CzBJ0=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=pjgvX0mp7DEwxcOFLR+4c/7Qp9Rmdq+nNdKNV+Q0vyj6VLf5wMWiyd+mjgkyhrOrB
	 4u0OqGsAoM3Ct6+KoG3x7loAbk69KmJs+sNmfZCJhGbuK5xTR6AiqgMzHgfQPG7CWA
	 C+BRh/9edpxsvzDPG+LCu6RHPhX61ZT5N2BgzCDA=
From: "syq at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/104914] [MIPS] wrong comparison with scrabbled
 int value
Date: Thu, 03 Aug 2023 09:34:07 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: rtl-optimization
X-Bugzilla-Version: 12.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: syq at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-104914-4-c3R6loCzxh@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-104914-4@http.gcc.gnu.org/bugzilla/>
References: <bug-104914-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

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

--- 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 implicit=
ly
> assumed to be (sign?) extended, then an arbitrary DImode value/register
> can't be used as an SImode value without appropriately setting/clearing t=
he
> upper bits.
> i.e. thus this integer truncation isn't a no-op.
>=20

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 <=3D 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=20
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.
>=20
> 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.=