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 BF17B3858C60; Fri, 20 Oct 2023 22:49:57 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BF17B3858C60
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1697842197;
	bh=sT8rG3z9J2wVMaxHXlREBRdYQADur7A7+M9Bgs2BKzE=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=jh5ZPayrGwS0NNLcuOISo3z04hMmZcGYII3Uwbk+i0bhcfMR/wS5OzZDACED2nDTg
	 4X6KKP7qO3QcRpL/eGLEGuN6h6CYk69ZXI68Rv0hVOtzLyMVgeIIh5QLEQEhz4Uzp6
	 NMqLgDDvtkkMSUFGlVEKS0XUKf72I1DNiTrYFQ4I=
From: "roger at nextmovesoftware dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/111267] [14 Regression] Codegen regression
 from i386 argument passing changes
Date: Fri, 20 Oct 2023 22:49:57 +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: 14.0
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: roger at nextmovesoftware dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 14.0
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-111267-4-GPyJ2s4ocA@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-111267-4@http.gcc.gnu.org/bugzilla/>
References: <bug-111267-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=3D111267

--- Comment #3 from Roger Sayle <roger at nextmovesoftware dot com> ---
This patch addresses the regression, but probably isn't the correct fix.

The issue is that the backend now has a way of representing the concatenati=
on
of two registers (for example, TI is constructed for two DI mode registers):

(set (reg:TI 111 [ bD.2764 ])
    (ior:TI (ashift:TI (zero_extend:TI (reg:DI 142))
            (const_int 64 [0x40]))
        (zero_extend:TI (reg:DI 141))))

But combine is unable to cleanly extract the (original) DI mode components =
back
out of this using SUBREGs.  Currently combine gets confused and attempts to
match things like:

Trying 10 -> 74:
   10: r111:TI=3Dzero_extend(r142:DI)<<0x40|zero_extend(r141:DI)
      REG_DEAD r141:DI
      REG_DEAD r142:DI
   74: r137:DI=3Dr111:TI#0
Failed to match this instruction:
(parallel [
        (set (reg:DI 137 [ bD.2764 ])
            (reg:DI 141))
        (set (reg:TI 111 [ bD.2764 ])
            (ior:TI (ashift:TI (zero_extend:TI (reg:DI 142))
                    (const_int 64 [0x40]))
                (zero_extend:TI (reg:DI 141))))
    ])

which contains the simplification we want, "reg:DI 137 :=3D reg:DI 141", but
along with stuff that combine should really take care off (strip/duplicate)=
.=20
I'll work on a more acceptable middle-end fix, but this patch demonstrates
progress, and can be used if a more general solution can't be found.=