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 29AE83858291; Wed, 17 Jan 2024 16:31:33 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 29AE83858291
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1705509093;
	bh=PY/lTSt2N7S7N4h88od9VsokIdfgNpBSa8d6msI8ELs=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=tT5HjOYGHFAVj2426CanR+D5ixz99pxoWr0kMnPa9tJifgqTvJ+Y5RDvp5ytSP4it
	 5Zz1allKaOJr6z7tdc8lW/M8+ZAqcJuLOBxC93HGkwLMCWpYCAZ9wOzzazq1UTZnqI
	 NWx9rLPzcB/nBWhO14OtZjjaoVqmT/ek4G7NZHjw=
From: "acoplan at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/113114] [14 Regression] ICE compiling
 gcc.c-torture/execute/pr59643.cwith -mabi=ilp32; in try_promote_writeback
 aarch64-ldp-fusion.cc
Date: Wed, 17 Jan 2024 16:31:32 +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, testsuite-fail
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-113114-4-OS4LlOjvd5@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-113114-4@http.gcc.gnu.org/bugzilla/>
References: <bug-113114-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=3D113114

--- Comment #5 from Alex Coplan <acoplan at gcc dot gnu.org> ---
Hmm, so initially (with the testcase in c3) we have:

ldp s30, s29, [x0, #-4]
...
add x0, x0, #-4

and we try to form:

ldp s30, s29, [x0, #-4]!

with this RTL:

(rr) call debug (pair_change.m_insn->rtl ())
(insn 47 18 20 3 (parallel [
            (set (reg:DI 0 x0 [119])
                (plus:DI (reg:DI 0 x0 [orig:101 ivtmp.12 ] [101])
                    (const_int -4 [0xfffffffffffffffc])))
            (set (reg:SF 62 v30 [orig:122 MEM[(float *)_18] ] [122])
                (mem:SF (plus:DI (reg:DI 0 x0 [orig:101 ivtmp.12 ] [101])
                        (const_int -4 [0xfffffffffffffffc])) [0 +0 S4 A32]))
            (set (reg:SF 61 v29 [orig:116 MEM[(float *)_18] ] [116])
                (mem:SF (reg:DI 0 x0 [orig:101 ivtmp.12 ] [101]) [0 +4 S4
A32]))
        ]) "t.c":6:7 -1
     (nil))

but the problem is that we're expecting to match this pattern:

;; Load pair with pre-index writeback.
(define_insn "*loadwb_pre_pair_<ldst_sz>"
  [(set (match_operand 0 "pmode_register_operand")
        (match_operator 8 "pmode_plus_operator" [
          (match_operand 1 "pmode_register_operand")
          (match_operand 4 "const_int_operand")]))
   (set (match_operand:GPI 2 "aarch64_ldp_reg_operand")
        (match_operator 6 "memory_operand" [
          (match_operator 9 "pmode_plus_operator" [
            (match_dup 1)
            (match_dup 4)
          ])]))
   (set (match_operand:GPI 3 "aarch64_ldp_reg_operand")
        (match_operator 7 "memory_operand" [
          (match_operator 10 "pmode_plus_operator" [
             (match_dup 1)
             (match_operand 5 "const_int_operand")
          ])]))]
  "aarch64_mem_pair_offset (operands[4], <MODE>mode)
   && known_eq (INTVAL (operands[5]),
                INTVAL (operands[4]) + GET_MODE_SIZE (<MODE>mode))"
  {@ [cons: =3D&0, 1, =3D2, =3D3; attrs: type     ]
     [       rk, 0,  r,  r; load_<ldpstp_sz>] ldp\t%<w>2, %<w>3, [%0, %4]!
     [       rk, 0,  w,  w; neon_load1_2reg ] ldp\t%<v>2, %<v>3, [%0, %4]!
  }
)

which simply doesn't match due to the shape of the RTL: that is, the pattern
hard-codes two plus operands, but due to the offset of -4 here we end up wi=
th
the second operand accessing memory directly at (the initial value of) x0.

We could add a second pattern to handle this specific case, or we could just
adjust try_promote_writeback to not assert that recog succeeds and accept t=
he
missed optimization for the time being.=