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 5C7633849AC4; Mon, 22 Apr 2024 19:45:38 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5C7633849AC4
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1713815138;
	bh=DGWr3Exv/149R6tYVstUuo1jLPNQSMnTBcOyi4S2lFE=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=xKjA4KVPj6WWAXqa1ZjGI+biX6JkViH0f6HR9JRQiHU7l4PniRqKlTVown+tju3Gf
	 NRw/A4MFnzn6330Uxv7L8866jwQpeNcAMP/LM9bxXFWqm/Bj+9vqVCqkIrbM2d1eFJ
	 QBrGpt76aXSMgo+lVNmRIZq7FimKuGYQPEiWsRzg=
From: "vmakarov at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/114810] [14 Regression] internal compiler
 error: in lra_split_hard_reg_for, at lra-assigns.cc:1868  (unable to find a
 register to spill) {*andndi3_doubleword_bmi} with -m32 -mstackrealign -O2
 -mbmi -fno-exceptions -fno-plt
Date: Mon, 22 Apr 2024 19:45:37 +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: ra
X-Bugzilla-Severity: normal
X-Bugzilla-Who: vmakarov at gcc dot gnu.org
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-114810-4-zGO4tl7eO0@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-114810-4@http.gcc.gnu.org/bugzilla/>
References: <bug-114810-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=3D114810

--- Comment #6 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
(In reply to Uro=C5=A1 Bizjak from comment #4)
> An interesting observation, when the insn is defined only with problematic
> alternative:
>=20
> (define_insn_and_split "*andn<dwi>3_doubleword_bmi"
>   [(set (match_operand:<DWI> 0 "register_operand" "=3D&r")
> 	(and:<DWI>
> 	  (not:<DWI> (match_operand:<DWI> 1 "register_operand" "r"))
> 	  (match_operand:<DWI> 2 "nonimmediate_operand" "ro")))
>    (clobber (reg:CC FLAGS_REG))]
>=20
> the compilation succeeds, and a spill to memory is emitted:
>=20
>=20
> (insn 1170 65 1177 7 (set (mem/c:DI (plus:SI (reg/f:SI 6 bp)
>                 (const_int -168 [0xffffffffffffff58])) [71 %sfp+-144 S8 A=
64])
>         (reg:DI 0 ax [orig:217 _13 ] [217])) "pr114810.C":296:36 84
> {*movdi_internal}
>      (nil))
>=20
> ...
>=20
> (insn 987 1154 1111 7 (parallel [
>             (set (reg:DI 3 bx [453])
>                 (and:DI (not:DI (reg:DI 0 ax [452]))
>                     (mem/c:DI (plus:SI (reg/f:SI 6 bp)
>                             (const_int -168 [0xffffffffffffff58])) [71
> %sfp+-144 S8 A64])))
>             (clobber (reg:CC 17 flags))
>         ]) "pr114810.C":296:6 703 {*andndi3_doubleword_bmi}
>      (nil))

The problem is that the alternative assumes 3 DI values live simultaneously=
.=20
This means 6 regs and we have only 6 available ones. One input reg is assig=
ned
to 0 another one is to 3.  So we have [01]2[34]5, where regs in brackets are
taken by the operands.  Although there are still 2 regs but they can not be
used as they are not adjacent.

The one solution is to somehow penalize the chosen alternative by changing
alternative heuristics in lra-constraints.cc.  But it definitely can affect
other targets in some unpredicted way.  So the solution is too risky especi=
ally
at this stage.  Also it might be possible that there is no alternative with
less 3 living pseudos for some different insn case.

I don't see non-risky solution right now.  I'll be thinking how to better f=
ix
this.=