[Bug target/113114] [14 Regression] ICE compiling gcc.c-torture/execute/pr59643.cwith -mabi=ilp32; in try_promote_writeback aarch64-ldp-fusion.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113114 Alex Coplan changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Alex Coplan --- Should be fixed, thanks for the report.
[Bug target/113114] [14 Regression] ICE compiling gcc.c-torture/execute/pr59643.cwith -mabi=ilp32; in try_promote_writeback aarch64-ldp-fusion.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113114 --- Comment #9 from GCC Commits --- The master branch has been updated by Alex Coplan : https://gcc.gnu.org/g:20e18106fac2d11ee43683291ff11d76da41d50b commit r14-8353-g20e18106fac2d11ee43683291ff11d76da41d50b Author: Alex Coplan Date: Thu Jan 18 17:53:01 2024 + aarch64: Don't assert recog success in ldp/stp pass [PR113114] The PR shows two different cases where try_promote_writeback produces an RTL pattern which isn't recognized. Currently this leads to an ICE, as we assert recog success, but I think it's better just to back out of the changes gracefully if recog fails (as we do in the main fuse_pair case). In theory since we check the ranges here recog shouldn't fail (which is why I had the assert in the first place), but the PR shows an edge case in the patterns where if we form a pre-writeback pair where the writeback offset is exactly -S, where S is the size in bytes of one transfer register, we fail to match the expected pattern as the patterns look explicitly for plus operands in the mems. I think fixing this would require adding at least four new special-case patterns to aarch64.md for what doesn't seem to be a particularly useful variant of the insns. Even if we were to do that, I think it would be GCC 15 material, and it's better to just punt for GCC 14. The ILP32 case in the PR is a bit different, as that shows us trying to combine a pair with DImode base register operands in the mems together with an SImode trailing update of the base register. This leads to us forming an RTL pattern which references the base register in both SImode and DImode, which also fails to recog. Again, I think it's best just to take the missed optimization for now. If we really want to make this (try_promote_writeback) work for ILP32, we can try to do it for GCC 15. gcc/ChangeLog: PR target/113114 * config/aarch64/aarch64-ldp-fusion.cc (try_promote_writeback): Don't assert recog success, just punt if the writeback pair isn't recognized. gcc/testsuite/ChangeLog: PR target/113114 * gcc.c-torture/compile/pr113114.c: New test. * gcc.target/aarch64/pr113114.c: New test.
[Bug target/113114] [14 Regression] ICE compiling gcc.c-torture/execute/pr59643.cwith -mabi=ilp32; in try_promote_writeback aarch64-ldp-fusion.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113114 Alex Coplan changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2024-January ||/643460.html Keywords||patch --- Comment #8 from Alex Coplan --- Patch submitted: https://gcc.gnu.org/pipermail/gcc-patches/2024-January/643460.html
[Bug target/113114] [14 Regression] ICE compiling gcc.c-torture/execute/pr59643.cwith -mabi=ilp32; in try_promote_writeback aarch64-ldp-fusion.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113114 --- Comment #7 from Alex Coplan --- Testing a fix.
[Bug target/113114] [14 Regression] ICE compiling gcc.c-torture/execute/pr59643.cwith -mabi=ilp32; in try_promote_writeback aarch64-ldp-fusion.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113114
--- Comment #6 from Alex Coplan ---
Hmm, it's worth noting that the ILP32 case is a bit different, though, in that
we have:
(rr) call debug (insn->rtl ())
(insn 16 21 19 3 (parallel [
(set (reg:DF 62 v30)
(unspec:DF [
(mem:V2x8QI (reg/v/f:DI 0 x0 [orig:123 a ] [123]) [0 +0
S16 A64])
] UNSPEC_LDP_FST))
(set (reg:DF 63 v31)
(unspec:DF [
(mem:V2x8QI (reg/v/f:DI 0 x0 [orig:123 a ] [123]) [0 +0
S16 A64])
] UNSPEC_LDP_SND))
]) 88 {*load_pair_8}
(nil))
(rr) call debug (trailing_add->rtl ())
(insn 20 18 41 3 (set (reg:SI 0 x0 [orig:118 ivtmp.22 ] [118])
(plus:SI (reg:SI 0 x0 [orig:123 a ] [123])
(const_int 8 [0x8]))) 119 {*addsi3_aarch64}
(nil))
i.e. x0 appears as DImode in the load pair addresses but the trailing update is
done in SImode, which means we end up not matching when forming the final
pattern.
I don't think either case is particularly interesting, so I'm leaning towards
just bailing out if recog fails in the pass (in which case both of these just
become missed-optimizations).
[Bug target/113114] [14 Regression] ICE compiling gcc.c-torture/execute/pr59643.cwith -mabi=ilp32; in try_promote_writeback aarch64-ldp-fusion.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113114
--- Comment #5 from Alex Coplan ---
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 [0xfffc])))
(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 [0xfffc])) [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_"
[(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)
&& known_eq (INTVAL (operands[5]),
INTVAL (operands[4]) + GET_MODE_SIZE (mode))"
{@ [cons: =&0, 1, =2, =3; attrs: type ]
[ rk, 0, r, r; load_] ldp\t%2, %3, [%0, %4]!
[ rk, 0, w, w; neon_load1_2reg ] ldp\t%2, %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 with
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 the
missed optimization for the time being.
[Bug target/113114] [14 Regression] ICE compiling gcc.c-torture/execute/pr59643.cwith -mabi=ilp32; in try_promote_writeback aarch64-ldp-fusion.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113114 --- Comment #4 from Alex Coplan --- (The above was reduced from gcc/testsuite/gcc.dg/torture/pr45720.c FWIW).
[Bug target/113114] [14 Regression] ICE compiling gcc.c-torture/execute/pr59643.cwith -mabi=ilp32; in try_promote_writeback aarch64-ldp-fusion.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113114
--- Comment #3 from Alex Coplan ---
The following ICEs in the same way without ILP32 (reduced from a testsuite run
with -funroll-loops):
$ cat t.c
float val[128];
float x;
void bar() {
int i = 55;
for (; i >= 0; --i)
x += val[i];
}
$ gcc/xgcc -B gcc -c t.c -O -funroll-loops -mearly-ldp-fusion -mlate-ldp-fusion
during RTL pass: ldp_fusion
t.c: In function ‘bar’:
t.c:7:1: internal compiler error: in try_promote_writeback, at
config/aarch64/aarch64-ldp-fusion.cc:2675
7 | }
| ^
0x14671b3 try_promote_writeback
/home/alecop01/toolchain/src/other_gcc/gcc/config/aarch64/aarch64-ldp-fusion.cc:2675
0x14671b3 ldp_fusion_bb(rtl_ssa::bb_info*)
/home/alecop01/toolchain/src/other_gcc/gcc/config/aarch64/aarch64-ldp-fusion.cc:2706
0x1467307 ldp_fusion()
/home/alecop01/toolchain/src/other_gcc/gcc/config/aarch64/aarch64-ldp-fusion.cc:2726
0x146737b execute
/home/alecop01/toolchain/src/other_gcc/gcc/config/aarch64/aarch64-ldp-fusion.cc:2776
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug target/113114] [14 Regression] ICE compiling gcc.c-torture/execute/pr59643.cwith -mabi=ilp32; in try_promote_writeback aarch64-ldp-fusion.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113114 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1 CC||jakub at gcc dot gnu.org
[Bug target/113114] [14 Regression] ICE compiling gcc.c-torture/execute/pr59643.cwith -mabi=ilp32; in try_promote_writeback aarch64-ldp-fusion.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113114 Alex Coplan changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2024-01-02 CC||acoplan at gcc dot gnu.org Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |acoplan at gcc dot gnu.org --- Comment #2 from Alex Coplan --- Confirmed, I can take a look.
[Bug target/113114] [14 Regression] ICE compiling gcc.c-torture/execute/pr59643.cwith -mabi=ilp32; in try_promote_writeback aarch64-ldp-fusion.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113114 Andrew Pinski changed: What|Removed |Added Keywords|needs-bisection | Summary|ICE in |[14 Regression] ICE |try_promote_writeback |compiling |aarch64-ldp-fusion.cc |gcc.c-torture/execute/pr596 ||43.cwith -mabi=ilp32; in ||try_promote_writeback ||aarch64-ldp-fusion.cc Target Milestone|--- |14.0 --- Comment #1 from Andrew Pinski --- Most likely r14-6605-gc0911c6b357ba9 when aarch64-ldp-fusion.cc was introduced.
