[Bug target/113623] [14 Regression] ICE in aarch64_pair_mem_from_base since r14-6605
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113623 Richard Sandiford changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Richard Sandiford --- Fixed.
[Bug target/113623] [14 Regression] ICE in aarch64_pair_mem_from_base since r14-6605
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113623
--- Comment #7 from GCC Commits ---
The trunk branch has been updated by Richard Sandiford :
https://gcc.gnu.org/g:fa2739ac1b74769d97fba34db9b9a8aa8786539e
commit r14-8519-gfa2739ac1b74769d97fba34db9b9a8aa8786539e
Author: Richard Sandiford
Date: Tue Jan 30 09:30:35 2024 +
aarch64: Avoid allocating FPRs to address registers [PR113623]
For something like:
void
foo (void)
{
int *ptr;
asm volatile ("%0" : "=w" (ptr));
asm volatile ("%0" :: "m" (*ptr));
}
early-ra would allocate ptr to an FPR for the first asm, thus
leaving an FPR address in the second asm. The address was then
reloaded by LRA to make it valid.
But early-ra shouldn't be allocating at all in that kind of
situation. Doing so caused the ICE in the PR (with LDP fusion).
Fixed by making sure that we record address references as
GPR references.
gcc/
PR target/113623
* config/aarch64/aarch64-early-ra.cc (early_ra::preprocess_insns):
Mark all registers that occur in addresses as needing a GPR.
gcc/testsuite/
PR target/113623
* gcc.c-torture/compile/pr113623.c: New test.
[Bug target/113623] [14 Regression] ICE in aarch64_pair_mem_from_base since r14-6605
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113623 Richard Sandiford changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org --- Comment #6 from Richard Sandiford --- Mine.
[Bug target/113623] [14 Regression] ICE in aarch64_pair_mem_from_base since r14-6605
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113623 --- Comment #5 from Alex Coplan --- Indeed passing -mearly-ra=none makes the ICE go away as well.
[Bug target/113623] [14 Regression] ICE in aarch64_pair_mem_from_base since r14-6605
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113623 Alex Coplan changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|acoplan at gcc dot gnu.org |unassigned at gcc dot gnu.org
[Bug target/113623] [14 Regression] ICE in aarch64_pair_mem_from_base since r14-6605
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113623 Alex Coplan changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org --- Comment #4 from Alex Coplan --- I think this is an early RA problem. In asmcons (in function qux), we have: 29: x1:DI=[r122:DI+0x8] 30: x0:DI=[r122:DI] and then in early_ra, we get: 29: x1:DI=[v31:DI+0x8] 30: x0:DI=[v31:DI] CCing Richard S for an opinion.
[Bug target/113623] [14 Regression] ICE in aarch64_pair_mem_from_base since r14-6605
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113623 --- Comment #3 from Alex Coplan --- I think ldp_fusion is exposing a latent issue here. We trip the assert: gcc_assert (aarch64_mem_pair_lanes_operand (mem, pair_mode)); on the RTL: (rr) pr mem (mem/f:V2x8QI (reg:DI 63 v31) [0 +0 S16 A64]) because v31 isn't a valid base register according to aarch64_regno_ok_for_base_p. This comes from the following RTL in sched1, where we already have: 30: x0:DI=[v31:DI] 29: x1:DI=[v31:DI+0x8] but again these mems look invalid as per aarch64_regno_ok_for_base_p.
[Bug target/113623] [14 Regression] ICE in aarch64_pair_mem_from_base since r14-6605
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113623 Alex Coplan changed: What|Removed |Added Status|NEW |ASSIGNED Known to fail||14.0 Target||aarch64-*-* Assignee|unassigned at gcc dot gnu.org |acoplan at gcc dot gnu.org --- Comment #2 from Alex Coplan --- Confirmed, mine.
[Bug target/113623] [14 Regression] ICE in aarch64_pair_mem_from_base since r14-6605
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113623 Jakub Jelinek changed: What|Removed |Added Summary|[14 Regression] ICE in |[14 Regression] ICE in |aarch64_pair_mem_from_base |aarch64_pair_mem_from_base ||since r14-6605 --- Comment #1 from Jakub Jelinek --- Started with r14-6605-gc0911c6b357ba916ae24926b7d8b9ca35234f33c -O3 -mno-early-ldp-fusion fixes it. Obviously in the range when these options were disabled by default it needs -O3 -mearly-ldp-fusion to reproduce.
