[Bug target/103676] [10/11/12 Regression] internal compiler error: in extract_constrain_insn, at recog.c:2671
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103676 --- Comment #24 from CVS Commits --- The master branch has been updated by Vladimir Makarov : https://gcc.gnu.org/g:85419ac59724b7ce710ebb4acf03dbd747edeea3 commit r12-6803-g85419ac59724b7ce710ebb4acf03dbd747edeea3 Author: Vladimir N. Makarov Date: Fri Jan 21 13:34:32 2022 -0500 [PR103676] LRA: Calculate and exclude some start hard registers for reload pseudos LRA and old reload pass uses only one register class for reload pseudos even if operand constraints contain more one register class. Let us consider constraint 'lh' for thumb arm which means low and high thumb registers. Reload pseudo for such constraint will have general reg class (union of low and high reg classes). Assigning the last low register to the reload pseudo is wrong if the pseudo is of DImode as it requires two hard regs. But it is considered OK if we use general reg class. The following patch solves this problem for LRA. gcc/ChangeLog: PR target/103676 * ira.h (struct target_ira): Add member x_ira_exclude_class_mode_regs. (ira_exclude_class_mode_regs): New macro. * lra.h (lra_create_new_reg): Add arg exclude_start_hard_regs and move from here ... * lra-int.h: ... to here. (lra_create_new_reg_with_unique_value): Add arg exclude_start_hard_regs. (class lra_reg): Add member exclude_start_hard_regs. * lra-assigns.cc (find_hard_regno_for_1): Setup impossible_start_hard_regs from exclude_start_hard_regs. * lra-constraints.cc (get_reload_reg): Add arg exclude_start_hard_regs and pass it lra_create_new_reg[_with_unique_value]. (match_reload): Ditto. (check_and_process_move): Pass NULL exclude_start_hard_regs to lra_create_new_reg_with_unique_value. (goal_alt_exclude_start_hard_regs): New static variable. (process_addr_reg, simplify_operand_subreg): Pass NULL exclude_start_hard_regs to lra_create_new_reg_with_unique_value and get_reload_reg. (process_alt_operands): Setup goal_alt_exclude_start_hard_regs. Use this_alternative_exclude_start_hard_regs additionally to find winning operand alternative. (base_to_reg, base_plus_disp_to_reg, index_part_to_reg): Pass NULL exclude_start_hard_regs to lra_create_new_reg. (process_address_1, emit_inc): Ditto. (curr_insn_transform): Pass exclude_start_hard_regs value to lra_create_new_reg, get_reload_reg, match_reload. (inherit_reload_reg, split_reg): Pass NULL exclude_start_hard_regs to lra_create_new_reg. (process_invariant_for_inheritance): Ditto. * lra-remat.cc (update_scratch_ops): Ditto. * lra.cc (lra_create_new_reg_with_unique_value): Add arg exclude_start_hard_regs. Setup the corresponding member of lra reg info. (lra_create_new_reg): Add arg exclude_start_hard_regs and pass it to lra_create_new_reg_with_unique_value. (initialize_lra_reg_info_element): Initialize member exclude_start_hard_regs. (get_scratch_reg): Pass NULL to lra_create_new_reg. * ira.cc (setup_prohibited_class_mode_regs): Rename to setup_prohibited_and_exclude_class_mode_regs and calculate ira_exclude_class_mode_regs. gcc/testsuite/ChangeLog: PR target/103676 * g++.target/arm/pr103676.C: New.
[Bug target/103676] [10/11/12 Regression] internal compiler error: in extract_constrain_insn, at recog.c:2671
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103676 --- Comment #23 from Vladimir Makarov --- (In reply to Jakub Jelinek from comment #22) > If we consider such an inline asm invalid, we could error on it, ICE is not > the right thing. But what exactly should we error on? Alternative I think it is better to fix it in LRA than describing the semantics. I am starting to work on it and will look how the fix is going. If it is too complicated, we could try another solution (with describing the current semantics). In any case, I think it is not worth to fix the same existing problem in the old reload pass. > containing multiple register classes for multi-word operands is still > something used quite commonly in real-world, the problem is when the RA > assigns it a reg spanning across those. Or do most backends restrict > multi-word regs to start at a reg number divisible by the number of words > they need?
[Bug target/103676] [10/11/12 Regression] internal compiler error: in extract_constrain_insn, at recog.c:2671
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103676 --- Comment #22 from Jakub Jelinek --- If we consider such an inline asm invalid, we could error on it, ICE is not the right thing. But what exactly should we error on? Alternative containing multiple register classes for multi-word operands is still something used quite commonly in real-world, the problem is when the RA assigns it a reg spanning across those. Or do most backends restrict multi-word regs to start at a reg number divisible by the number of words they need?
[Bug target/103676] [10/11/12 Regression] internal compiler error: in extract_constrain_insn, at recog.c:2671
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103676 --- Comment #21 from Vladimir Makarov --- (In reply to Jakub Jelinek from comment #19) > r10-3981-gf6ff841bc8dd87ce364deb217dc6d1ec5dc31de8 still doesn't ICE, > r10-3984-g22060d0e575e7754eb1355763d22bbe37c3caa13 already ICEs. > > I guess there is a disagreement between LRA and recog on how exactly they > treat register constraints. > "=lh" for TARGET_THUMB means LO_REGS or HI_REGS classes for the output, bet > LRA sees that LO_REGS or HI_REGS is together GENERAL_REGS and picks a > GENERAL_REGS > (reg:DI 7 r7 [orig:119 tmp ] [119]). But that one has one half in LO_REGS > and another half in HI_REGS and so extract_constrain_insn -> > constrain_operands > doesn't consider it as matching. Interesting case. To find required (reload) register class, LRA (as also the old reload pass) makes some union of register classes in one alternative which contains all or part of the registers of the classes (in this case it is general reg class). The problem can be solved w/o fixing LRA (and reload pass) by using asm volatile( "ldrd %Q[r], %R[r], %[p]\n" : [r]"=l,h"(tmp) : [p]"m,m"(*p64) : "memory" ); The problem can be solved in LRA by more complex representation of required reg classes (still reload should have also such fix). I guess it will complicate LRA and reload code a lot. We could also use more clear description of semantics of constraints currently used by LRA/reload. In this case we still need to output more meaningful error for LRA/reload instead of just internal compiler error.
[Bug target/103676] [10/11/12 Regression] internal compiler error: in extract_constrain_insn, at recog.c:2671
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103676 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug target/103676] [10/11/12 Regression] internal compiler error: in extract_constrain_insn, at recog.c:2671
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103676 --- Comment #20 from Jakub Jelinek --- BTW, I needed -mcpu=cortex-m7 -mthumb -O2 to reproduce the ICE.
[Bug target/103676] [10/11/12 Regression] internal compiler error: in extract_constrain_insn, at recog.c:2671
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103676 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||rearnsha at gcc dot gnu.org, ||vmakarov at gcc dot gnu.org Keywords|needs-bisection | --- Comment #19 from Jakub Jelinek --- r10-3981-gf6ff841bc8dd87ce364deb217dc6d1ec5dc31de8 still doesn't ICE, r10-3984-g22060d0e575e7754eb1355763d22bbe37c3caa13 already ICEs. I guess there is a disagreement between LRA and recog on how exactly they treat register constraints. "=lh" for TARGET_THUMB means LO_REGS or HI_REGS classes for the output, bet LRA sees that LO_REGS or HI_REGS is together GENERAL_REGS and picks a GENERAL_REGS (reg:DI 7 r7 [orig:119 tmp ] [119]). But that one has one half in LO_REGS and another half in HI_REGS and so extract_constrain_insn -> constrain_operands doesn't consider it as matching.
[Bug target/103676] [10/11/12 Regression] internal compiler error: in extract_constrain_insn, at recog.c:2671
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103676 Andrew Pinski changed: What|Removed |Added Keywords||ra --- Comment #18 from Andrew Pinski --- (In reply to Andrew Pinski from comment #16) > Here is the most reduced testcase, I could make it: Note only -O2 -mthumb to reproduce this issue on arm-linux-gnueabi. It looks register allocation related. If I used "=l" or "=h" constraint alone, it works but not if used together.
[Bug target/103676] [10/11/12 Regression] internal compiler error: in extract_constrain_insn, at recog.c:2671
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103676 --- Comment #17 from Andrew Pinski --- (In reply to Patrick Oppenlander from comment #13) > That should be the one. Thanks for all the help! Thanks for the preprocessed source, it made it easier to make the testcase that was a single file.
[Bug target/103676] [10/11/12 Regression] internal compiler error: in extract_constrain_insn, at recog.c:2671
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103676
--- Comment #16 from Andrew Pinski ---
Here is the most reduced testcase, I could make it:
typedef unsigned long long uint64_t;
struct timer {
int active;
uint64_t expire;
void *arg;
};
int irq_disable();
void irq_restore(int);
static inline uint64_t h(const uint64_t *p64)
{
uint64_t tmp;
asm(
"ldrd %Q[r], %R[r], %[p]\n"
: [r]"=lh"(tmp)
: [p]"m"(*p64)
: "memory"
);
return tmp;
}
uint64_t monotonic;
void timer_callout(timer *tmr, uint64_t nsec, void *arg)
{
const int s = irq_disable();
if (tmr->active)
tmr->arg = arg;
tmr->expire = h(&monotonic) + 10 + (nsec == 1 ? 0 : nsec);
irq_restore(s);
}
[Bug target/103676] [10/11/12 Regression] internal compiler error: in extract_constrain_insn, at recog.c:2671
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103676 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |10.4 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Known to fail||10.3.0 Last reconfirmed|2021-12-12 00:00:00 |2021-12-14 Known to work||9.3.0 Summary|internal compiler error: in |[10/11/12 Regression] |extract_constrain_insn, at |internal compiler error: in |recog.c:2671|extract_constrain_insn, at ||recog.c:2671 --- Comment #15 from Andrew Pinski --- Confirmed. It looks like it worked in GCC 9.3.0 (note remove -std=c++20 as it is no longer needed).
