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 DE55A3858D38; Wed,  1 May 2024 13:19:51 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DE55A3858D38
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1714569591;
	bh=pKuR8PspbHV8al5zBB+TnYnMISL4HksGkcZMGKBqo90=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=u7D3NNK7PYVYilFuMRaPCxhUjztZFY+Ee7uFVCp26aVBk2hZlwsEE0y7J2/Ly6mGG
	 bdPtvL/tQDN7BISJXsRssohWepejqKbSvO3p8hk9MDb232p2iEQ0m2afsItNxiNQ7q
	 GiYR90Y8W813qoxkBtA4k0XaImNmG6CDrlYsqVTI=
From: "jeevitha at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/101345] wrong code at -O1 with vector modulo
Date: Wed, 01 May 2024 13:19:50 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 12.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jeevitha at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: FIXED
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-101345-4-cbihcYBZ5g@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-101345-4@http.gcc.gnu.org/bugzilla/>
References: <bug-101345-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=3D101345

--- Comment #3 from Jeevitha <jeevitha at gcc dot gnu.org> ---

> Jeevitha, can you please do a git bisect from the two commits above to
> identify the commit that fixes this for posterity sake?  Thanks.

The commit that resolved the incorrect code was
ad5f8ac1d2f2dc92d43663243b52f9e9eb3cf7c0, where Bill disabled the swap for =
mult
with subreg. This addressed the issue.

The reason behind this change is as follows:

The input for the swap pass is,

insn 23 set r144, vec_concat(r152,r160)
insn 26 set r162, r237*(r144+0)
insn 27 set r163, (r144+8)*r236
insn 29 set r166, r236*(r144+0)
insn 30 set r167, subreg(r236*(r144+0),8)


Output from swap pass is,

insn 23 set r144, vec_concat(r160,r152)
insn 26 set r162, r237*(r144+8)
insn 27 set r163, (r144+0)*r236
insn 29 set r166, r236*(r144+8)
insn 30 set r167, subreg(r236*(r144+8),0)

In the provided sample code, multiplication operations are performed. Here,=
 the
SUBREG_BYTE changes in pseudo 144 are correct. However, the change from 8 t=
o 0
in the SUBREG_BYTE of MULT(r236,r144) is incorrect. This alteration leads to
treating it as a low-part multiply ie, similar to insn 29, whereas it should
actually a high-part multiply. Therefore, Bill stopped the swap for mult wi=
th
subreg case, which resolves this issue.

To provide clear reference, here is the RTL for insn 30 in failure case:

(insn 30 29 31 2 (set (reg:DI 167)
        (subreg:DI (mult:TI (zero_extend:TI (reg:DI 236))
-              (zero_extend:TI (subreg:DI (reg:V2DI 144) 0))) 8))
"test1.c":13:5 166 {umuldi3_highpart_le} //input from swap pass
+               (zero_extend:TI (subreg:DI (reg:V2DI 144) 8))) 0))
"test1.c":13:5 166=20
{umuldi3_highpart_le} //output from swap pass=