From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 8D0DE3849ADC; Fri, 19 Apr 2024 22:04:19 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8D0DE3849ADC DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1713564259; bh=638LpcCtMj+iAOWfYEN9M8BSgOnE+FTP6S5Qy/uV6co=; h=From:To:Subject:Date:In-Reply-To:References:From; b=YiUeFSb1ehP33D1Xf1OxIprvLePXw+nAmvMGuJ9KmMZNOTo2FAqA9IsPmy7hnP4cV TW4k8/LkNvb4/cgpkAvl/Yv7dFcaFSoXanaPy758QVYUGYe3MVU5kfRzssPNMA6URh cIVB5lzG3xMxvFTWArGibLM4q4dHZ00kjiEmakxg= From: "vmakarov at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/114766] ^ constraint modifier unexpectedly affects register class selection. Date: Fri, 19 Apr 2024 22:04:18 +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, ra X-Bugzilla-Severity: normal X-Bugzilla-Who: vmakarov at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED 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: In-Reply-To: References: 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: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D114766 --- Comment #1 from Vladimir Makarov --- (In reply to Tamar Christina from comment #0) > The documentation for ^ states: >=20 > "This constraint is analogous to =E2=80=98?=E2=80=99 but it disparages sl= ightly the > alternative only if the operand with the =E2=80=98^=E2=80=99 needs a relo= ad." >=20 >=20 > The penalty here seems incorrect, and removing it seems to get the > constraint to work properly. > So the question is, is it a bug, or are we using it incorrectly? or a > documentation bug? The current behavior of '^' is how it was originally planned.=20 With this point of view I would say that it is a documentation ambiguity.=20 documentation of '?' also does not clearly say about its affect on the cost calculation and as a consequence on choosing register class. On the other hand, I don't know what is really needed. If you need what you expected, please try the following patch: diff --git a/gcc/ira-costs.cc b/gcc/ira-costs.cc index c86c5a16563..04d2f21b023 100644 --- a/gcc/ira-costs.cc +++ b/gcc/ira-costs.cc @@ -771,10 +771,6 @@ record_reg_classes (int n_alts, int n_ops, rtx *ops, c =3D *++p; break; - case '^': - alt_cost +=3D 2; - break; - case '?': alt_cost +=3D 2; break; If it works for you, we could try to use the patch (although it needs some investigation how other targets uses the hint). In any case, the documenta= tion should be modified or made more clear depending on applying or not applying= the patch.=