From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 8B436394481A; Wed, 28 Apr 2021 16:55:01 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8B436394481A From: "cvs-commit at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/100305] [11/12 Regression] aarch64: ICE in output_operand_lossage with -O3 Date: Wed, 28 Apr 2021 16:55:01 +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: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: cvs-commit at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: rsandifo at gcc dot gnu.org X-Bugzilla-Target-Milestone: 11.2 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 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2021 16:55:01 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D100305 --- Comment #8 from CVS Commits --- The master branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:668df9e769e7d89bcefa07f72b68dcae9a8f3970 commit r12-219-g668df9e769e7d89bcefa07f72b68dcae9a8f3970 Author: Richard Sandiford Date: Wed Apr 28 17:54:52 2021 +0100 aarch64: Fix address mode for vec_concat pattern [PR100305] The load_pair_lanes patterns match a vec_concat of two adjacent 64-bit memory locations as a single 128-bit load. The Utq constraint made sure that the address was suitable for a 128-bit vector, but this meant that it allowed some addresses that aren't valid for the 64-bit element mode. Two obvious fixes were: (1) Continue to accept addresses that aren't valid for the element modes. This would mean changing the mode of operands[1] before printing it. It would also mean using a custom predicate instead of the current memory_operand. (2) Restrict addresses to the intersection of those that are valid element and vector addresses. The problem with (1) is that, as well as being more complicated, it doesn't deal with the fact that we still have a memory_operand for the second element. If we encourage the first operand to be outside the range of a normal element memory_operand, we'll have to reload the second operand to make it valid. This reload will often be dead code, but will be kept around because the RTL pattern makes it look as though the second element address is still needed. This patch therefore does (2) instead. As mentioned in the PR notes, I think we have a general problem with the way that the aarch64 port deals with paired addresses. There's nothing to guarantee that the two addresses will be reloaded in a way that keeps them =C3=A2obviously=C3=A2 adjacent, so the rtx_equal_p conditions could fail if something rechecked them later. For this particular pattern, I think it would be better to teach simplify-rtx.c to fold the vec_concat to a normal vector memory reference, to remove any suggestion that targets should try to match the unsimplified form. That obviously wouldn't be suitable for backports though. gcc/ PR target/100305 * config/aarch64/constraints.md (Utq): Require the address to be valid for both the element mode and for V2DImode. gcc/testsuite/ PR target/100305 * gcc.c-torture/compile/pr100305.c: New test.=