From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 3B5FC385840C; Tue, 23 Jan 2024 16:50:50 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3B5FC385840C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1706028650; bh=SSjBnDZSJnD6tFKGCYngRr4ton1A92xxpj/MM2BRcSs=; h=From:To:Subject:Date:In-Reply-To:References:From; b=f+n/hMfmHHgAD3nSUi2Z1mXd1BB/28TD3j9ryTT/quLcdkapC6IgPlBHf1P0SY1jq RiltEEIkDD8jTuNscZvDScwCgTQ+jxVyMRlnnbz0Zdw74Y4gxytwPF40dlP4c8mXXS L3Wyt1Ngi+0Ujn0RwJrfGnaslNLG/v31/cS8eFHs= From: "cvs-commit at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/113356] [14 Regression][aarch64] ICE in try_fuse_pair, at config/aarch64/aarch64-ldp-fusion.cc:2203 since r14-6947-g4b67ec7ff5b1aa Date: Tue, 23 Jan 2024 16:50:49 +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: 14.0 X-Bugzilla-Keywords: ice-on-valid-code, patch X-Bugzilla-Severity: normal X-Bugzilla-Who: cvs-commit at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: acoplan at gcc dot gnu.org X-Bugzilla-Target-Milestone: 14.0 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=3D113356 --- Comment #5 from GCC Commits --- The master branch has been updated by Alex Coplan : https://gcc.gnu.org/g:639ae543449a8d6525303458497bd4b897660ec3 commit r14-8367-g639ae543449a8d6525303458497bd4b897660ec3 Author: Alex Coplan Date: Mon Jan 15 11:07:48 2024 +0000 aarch64: Don't record hazards against paired insns [PR113356] For the testcase in the PR, we try to pair insns where the first has writeback and the second uses the updated base register. This causes us to record a hazard against the second insn, thus narrowing the move range away from the end of the BB. However, it isn't meaningful to record hazards against the other insn in the pair, as this doesn't change which pairs can be formed, and also doesn't change where the pair is formed (from the perspective of nondebug insns). To see why this is the case, consider the two cases: - Suppoe we are finding hazards for insns[0]. If we record a hazard against insns[1], then range.last becomes insns[1]->prev_nondebug_insn (), but note that this is equivalent to inserting after insns[1] (since insns[1] is being changed). - Now consider finding hazards for insns[1]. Suppose we record insns[0] as a hazard. Then we set range.first =3D insns[0], which i= s a no-op. As such, it seems better to never record hazards against the other insn in the pair, as we check whether the insns themselves are suitable for combination separately (e.g. for ldp checking that they use distinct transfer registers). Avoiding unnecessarily narrowing the move range avoids unnecessarily re-ordering over debug insns. This should also mean that we can only narrow the move range away from the end of the BB in the case that we record a hazard for insns[0] against insns[1]->prev_nondebug_insn () or earlier. This means that for the non-call-exceptions case, either the move range includes insns[1], or we reject the pair (thus the assert tripped in the PR should always hold). gcc/ChangeLog: PR target/113356 * config/aarch64/aarch64-ldp-fusion.cc (ldp_bb_info::try_fuse_pair): Don't record hazards against the opposite insn in the pair. gcc/testsuite/ChangeLog: PR target/113356 * gcc.target/aarch64/pr113356.C: New test.=