[Bug target/103074] [11/12 Regression] ICE in lra_assign, at lra-assigns.c:1649 since r11-5066-gbe39636d9f68c437
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103074 Richard Biener changed: What|Removed |Added Target Milestone|11.3|11.4 --- Comment #6 from Richard Biener --- GCC 11.3 is being released, retargeting bugs to GCC 11.4.
[Bug target/103074] [11/12 Regression] ICE in lra_assign, at lra-assigns.c:1649 since r11-5066-gbe39636d9f68c437
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103074 --- Comment #5 from CVS Commits --- The master branch has been updated by Vladimir Makarov : https://gcc.gnu.org/g:d8e5fff6b74b82c2ac3254be9a1f0fb6b30dbdbf commit r12-7604-gd8e5fff6b74b82c2ac3254be9a1f0fb6b30dbdbf Author: Vladimir N. Makarov Date: Thu Mar 10 16:16:00 2022 -0500 [PR103074] LRA: Check new conflicts when splitting hard reg live range. Splitting hard register live range can create (artificial) conflict of the hard register with another pseudo because of simplified conflict calculation in LRA. We should check such conflict on the next assignment sub-pass and spill and reassign the pseudo if necessary. The patch implements this. gcc/ChangeLog: PR target/103074 * lra-constraints.cc (split_reg): Set up check_and_force_assignment_correctness_p when splitting hard register live range. gcc/testsuite/ChangeLog: PR target/103074 * gcc.target/i386/pr103074.c: New.
[Bug target/103074] [11/12 Regression] ICE in lra_assign, at lra-assigns.c:1649 since r11-5066-gbe39636d9f68c437
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103074
--- Comment #4 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #3)
> Ah, actually what I see is that sched1 swaps the order of:
> (insn 22 21 23 4 (parallel [
> (set (reg:SI 88)
> (ashiftrt:SI (reg/v:SI 84 [ a ])
> (const_int 32 [0x20])))
> (clobber (reg:CC 17 flags))
> ]) "pr103074.c":10:7 735 {*ashrsi3_1}
> (expr_list:REG_UNUSED (reg:CC 17 flags)
> (nil)))
> (insn 23 22 24 4 (set (reg:SI 2 cx)
> (reg/v:SI 84 [ a ])) "pr103074.c":10:7 77 {*movsi_internal}
> (expr_list:REG_DEAD (reg/v:SI 84 [ a ])
> (nil)))
> and doing a shift when cx is live isn't an option because the shift needs
> the hard register for this shift amount (the constraints are Ic and I is
> 0..31 constant, c is %cx register).
Schedulers should not move insns that set TARGET_CLASS_LIKELY_SPILLED_P (that
includes CREG) before reload. See the comment in sched-rgn.c,
add_branch_dependencies.
[Bug target/103074] [11/12 Regression] ICE in lra_assign, at lra-assigns.c:1649 since r11-5066-gbe39636d9f68c437
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103074
--- Comment #3 from Jakub Jelinek ---
Ah, actually what I see is that sched1 swaps the order of:
(insn 22 21 23 4 (parallel [
(set (reg:SI 88)
(ashiftrt:SI (reg/v:SI 84 [ a ])
(const_int 32 [0x20])))
(clobber (reg:CC 17 flags))
]) "pr103074.c":10:7 735 {*ashrsi3_1}
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
(insn 23 22 24 4 (set (reg:SI 2 cx)
(reg/v:SI 84 [ a ])) "pr103074.c":10:7 77 {*movsi_internal}
(expr_list:REG_DEAD (reg/v:SI 84 [ a ])
(nil)))
and doing a shift when cx is live isn't an option because the shift needs the
hard register for this shift amount (the constraints are Ic and I is 0..31
constant, c is %cx register).
[Bug target/103074] [11/12 Regression] ICE in lra_assign, at lra-assigns.c:1649 since r11-5066-gbe39636d9f68c437
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103074 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||vmakarov at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- The comment above ix86_hardreg_mov_ok doesn't match the implementation, it doesn't prevent it before reload but before and during reload (LRA). So I'd have expected: --- gcc/config/i386/i386.c 2021-11-22 10:07:01.336225481 +0100 +++ gcc/config/i386/i386.c 2021-11-22 18:54:22.288643063 +0100 @@ -19367,7 +19367,8 @@ ix86_hardreg_mov_ok (rtx dst, rtx src) ? standard_sse_constant_p (src, GET_MODE (dst)) : x86_64_immediate_operand (src, GET_MODE (dst))) && ix86_class_likely_spilled_p (REGNO_REG_CLASS (REGNO (dst))) - && !reload_completed) + && !reload_completed + && !lra_in_progress) return false; return true; } but, that doesn't really fix it and it is unclear what LRA is unhappy about to me.
[Bug target/103074] [11/12 Regression] ICE in lra_assign, at lra-assigns.c:1649 since r11-5066-gbe39636d9f68c437
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103074 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |11.3
[Bug target/103074] [11/12 Regression] ICE in lra_assign, at lra-assigns.c:1649 since r11-5066-gbe39636d9f68c437
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103074 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org, ||roger at nextmovesoftware dot com Last reconfirmed||2021-11-04 Summary|[11/12 Regression] ICE in |[11/12 Regression] ICE in |lra_assign, at |lra_assign, at |lra-assigns.c:1649 |lra-assigns.c:1649 since ||r11-5066-gbe39636d9f68c437 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Martin Liška --- Confirmed, started with r11-5066-gbe39636d9f68c437.
