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 20A943858D28; Fri, 12 Jan 2024 15:07:28 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 20A943858D28
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1705072048;
	bh=iWzXGbmb60jGRvuWiGSGT5uI244WdWGUtMfh9UwJ6d4=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=rckPxVqpizahvSt9PpNAfPgIl+5bq16q+4WnRC1PuZ9YYo0OyPbL9FU5M5MD1W9T5
	 4I4/eqeUodxUR5b8QTCD9InqnX7hiYkMzIQ5SdBSZ1GZGNmmHscJZcFnPJsm0PyUBm
	 qRmWJaAyNy6EGxm13OEKCD1fGQ8RgRGWfsyjVJAs=
From: "acoplan at gcc dot gnu.org" <gcc-bugzilla@gcc.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: Fri, 12 Jan 2024 15:07:27 +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
X-Bugzilla-Severity: normal
X-Bugzilla-Who: acoplan 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: <bug-113356-4-rk6PUvX6iW@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-113356-4@http.gcc.gnu.org/bugzilla/>
References: <bug-113356-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=3D113356

--- Comment #2 from Alex Coplan <acoplan at gcc dot gnu.org> ---
So we have this IR:

    insn i8 in bb2 [ebb2] at point 18:
      +----------------------------
      |    8: [r104:DI++]=3Dr101:DI
      |      REG_DEAD r101:DI
      |      REG_INC r104:DI
      +----------------------------
      has pre/post-modify operations
      uses:
        use of set r101:i7 (DI pseudo)
        use of set r104:i17 (DI pseudo)
          appears in a read/write context
      defines:
        set r104:i8 (DI pseudo)
          set by a pre/post-modify
          appears in a read/write context
          used by insn i13 in bb2 [ebb2] at point 24
        set mem:i8

    insn i11 in bb2 [ebb2] at point 20:
      +------------------------------------------------
      |   11: r106:DI=3Dhigh(const(`_ZTV6Class1'+0x10))
      +------------------------------------------------
      defines:
        set r106:i11 (DI pseudo)
          used by insn i12 in bb2 [ebb2] at point 22

    insn i12 in bb2 [ebb2] at point 22:
      +-------------------------------------------------------
      |   12: r105:DI=3Dr106:DI+low(const(`_ZTV6Class1'+0x10))
      |      REG_DEAD r106:DI
      |      REG_EQUAL const(`_ZTV6Class1'+0x10)
      +-------------------------------------------------------
      uses:
        use of set r106:i11 (DI pseudo)
      defines:
        set r105:i12 (DI pseudo)
          used by insn i13 in bb2 [ebb2] at point 24

    insn i13 in bb2 [ebb2] at point 24:
      +----------------------------------------
      |   13: [r104:DI]=3Dr105:DI
      |      REG_DEAD r105:DI
      |      REG_DEAD r104:DI
      |      REG_EH_REGION 0xffffffffffffffff
      +----------------------------------------
      uses:
        use of set r104:i8 (DI pseudo)
          appears inside an address
        use of set r105:i12 (DI pseudo)
      defines:
        set mem:i13
          used by phi node mem:a7 in ebb1 at point 30

and we're trying to form (8,13).  i8 has i13 as a hazard due to the writeba=
ck
dataflow and i13 has i12 as a hazard (due to the initial fix for non-call
exceptions introducing a hazard on the previous nondebug insn).  I wonder i=
f it
would be enough to get i=