[Bug target/97532] [11 Regression] Error: insn does not satisfy its constraints, internal compiler error: in extract_constrain_insn, at recog.c:2196
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97532 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #16 from Jakub Jelinek --- .
[Bug target/97532] [11 Regression] Error: insn does not satisfy its constraints, internal compiler error: in extract_constrain_insn, at recog.c:2196
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97532 --- Comment #15 from Hongtao.liu --- Fixed in GCC11.
[Bug target/97532] [11 Regression] Error: insn does not satisfy its constraints, internal compiler error: in extract_constrain_insn, at recog.c:2196
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97532 --- Comment #14 from CVS Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:db8b3e148d5cc5358cd48886e5334bd50d2d3317 commit r11-4703-gdb8b3e148d5cc5358cd48886e5334bd50d2d3317 Author: liuhongt Date: Mon Oct 26 20:45:23 2020 +0800 Fix invalid address for special_memory_constraint. gcc/ChangeLog PR target/97532 * lra-constraints.c (valid_address_p): Handle operand of special memory constraint. (process_address_1): Ditto.
[Bug target/97532] [11 Regression] Error: insn does not satisfy its constraints, internal compiler error: in extract_constrain_insn, at recog.c:2196
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97532 --- Comment #13 from Hongtao.liu --- (In reply to Tom de Vries from comment #12) > (In reply to Hongtao.liu from comment #10) > > Created attachment 49444 [details] > > Fix invalid address for special memory constraint > > > > I'm testing this patch. > > Submitted: https://gcc.gnu.org/pipermail/gcc-patches/2020-October/557142.html Assume you are asking for when would this patch be submitted.(In reply to Tom de Vries from comment #12) > (In reply to Hongtao.liu from comment #10) > > Created attachment 49444 [details] > > Fix invalid address for special memory constraint > > > > I'm testing this patch. > > Submitted: https://gcc.gnu.org/pipermail/gcc-patches/2020-October/557142.html Related discussion at https://gcc.gnu.org/pipermail/gcc-patches/2020-October/557143.html
[Bug target/97532] [11 Regression] Error: insn does not satisfy its constraints, internal compiler error: in extract_constrain_insn, at recog.c:2196
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97532 --- Comment #12 from Tom de Vries --- (In reply to Hongtao.liu from comment #10) > Created attachment 49444 [details] > Fix invalid address for special memory constraint > > I'm testing this patch. Submitted: https://gcc.gnu.org/pipermail/gcc-patches/2020-October/557142.html
[Bug target/97532] [11 Regression] Error: insn does not satisfy its constraints, internal compiler error: in extract_constrain_insn, at recog.c:2196
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97532 Richard Biener changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #11 from Richard Biener --- *** Bug 97606 has been marked as a duplicate of this bug. ***
[Bug target/97532] [11 Regression] Error: insn does not satisfy its constraints, internal compiler error: in extract_constrain_insn, at recog.c:2196
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97532 --- Comment #10 from Hongtao.liu --- Created attachment 49444 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49444=edit Fix invalid address for special memory constraint I'm testing this patch.
[Bug target/97532] [11 Regression] Error: insn does not satisfy its constraints, internal compiler error: in extract_constrain_insn, at recog.c:2196
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97532 --- Comment #9 from Vladimir Makarov --- (In reply to Hongtao.liu from comment #6) > > > Shouldn't memory_operand (XEXP (op, 0), GET_MODE (XEXP (op, 0))) imply > legitimate_address_p? memory_operand does not imply legitimate_address_p. When LRA processes regular memory it calls legitimate_address_p. But for special memory it did not do this. It is a responsibility of special constraint to check it. That is why it is called special (it might require more constraints on addressing or hard registers can be used). I guess you should check it in the constraint that base and index registers are of the right class.
[Bug target/97532] [11 Regression] Error: insn does not satisfy its constraints, internal compiler error: in extract_constrain_insn, at recog.c:2196
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97532
--- Comment #8 from Hongtao.liu ---
(In reply to Jakub Jelinek from comment #7)
> memory_operand calls general_operand which for MEM does:
> /* Use the mem's mode, since it will be reloaded thus. LRA can
> generate move insn with invalid addresses which is made valid
> and efficiently calculated by LRA through further numerous
> transformations. */
> if (lra_in_progress
> || memory_address_addr_space_p (GET_MODE (op), y, MEM_ADDR_SPACE
> (op)))
> return 1;
> So, during LRA it accepts anything, and at the end of LRA it ICEs because it
> isn't recognized.
> So, I think LRA needs to know somewhere what is the address operand of the
> MEM even inside of the bcst_mem_operand and know that it should fix it up.
Yes, and i saw at least two places needed to be adjusted.
First in process_address_1 (int nop, bool check_only_p,
---
3430 /* Do not attempt to decompose arbitrary addresses generated by combine
3431 for asm operands with loose constraints, e.g 'X'. */
3432 else if (MEM_P (op) ---> Here!!!
3433&& !(INSN_CODE (curr_insn) < 0
3434 && get_constraint_type (cn) == CT_FIXED_FORM
3435 && constraint_satisfied_p (op, cn)))
3436 decompose_mem_address (, op);
3437 else if (GET_CODE (op) == SUBREG
3438&& MEM_P (SUBREG_REG (op)))
3439 decompose_mem_address (, SUBREG_REG (op));
3440 else
3441 return false;
---
Then in valid_address_p which would be called in process_address_1
---
398 /* Return true if the eliminated form of AD is a legitimate target
address.
399If OP is a MEM, AD is the address within OP, otherwise OP should be
400ignored. CONSTRAINT is one constraint that the operand may need
401to meet. */
402 static bool
403 valid_address_p (rtx op, struct address_info *ad,
404 enum constraint_num constraint)
405 {
406 address_eliminator eliminator (ad);
407
408 /* Allow a memory OP if it matches CONSTRAINT, even if CONSTRAINT is
more
409 forgiving than "m". */
410 if (MEM_P (op) ---> Here.
411 && (insn_extra_memory_constraint (constraint)
412 || insn_extra_special_memory_constraint (constraint))
413 && constraint_satisfied_p (op, constraint))
414 return true;
415
416 return valid_address_p (ad->mode, *ad->outer, ad->as);
417 }
---
[Bug target/97532] [11 Regression] Error: insn does not satisfy its constraints, internal compiler error: in extract_constrain_insn, at recog.c:2196
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97532 --- Comment #7 from Jakub Jelinek --- memory_operand calls general_operand which for MEM does: /* Use the mem's mode, since it will be reloaded thus. LRA can generate move insn with invalid addresses which is made valid and efficiently calculated by LRA through further numerous transformations. */ if (lra_in_progress || memory_address_addr_space_p (GET_MODE (op), y, MEM_ADDR_SPACE (op))) return 1; So, during LRA it accepts anything, and at the end of LRA it ICEs because it isn't recognized. So, I think LRA needs to know somewhere what is the address operand of the MEM even inside of the bcst_mem_operand and know that it should fix it up.
[Bug target/97532] [11 Regression] Error: insn does not satisfy its constraints, internal compiler error: in extract_constrain_insn, at recog.c:2196
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97532 Hongtao.liu changed: What|Removed |Added CC||crazylht at gmail dot com --- Comment #6 from Hongtao.liu --- (In reply to Vladimir Makarov from comment #4) > (In reply to Jakub Jelinek from comment #3) > > The IRA dump says: > > a2(r189,l0) costs: AREG:2000,2000 DREG:2000,2000 CREG:26000,-1000 > > BREG:2000,2000 SIREG:2000,2000 DIREG:2000,2000 AD_REGS:2000,2000 > > CLOBBERED_REGS > > :2000,2000 Q_REGS:2000,2000 TLS_GOTBASE_REGS:2000,2000 > > GENERAL_REGS:2000,2000 SSE_FIRST_REG:12000,12000 NO_REX_SSE_REGS:12000,12000 > > SSE_REGS:12000, > > 12000 ALL_SSE_REGS:12000,12000 MMX_REGS:26000,26000 INT_SSE_REGS:26000,26000 > > ALL_REGS:424000,424000 MEM:12000,12000 > > so the INT_SSE_REGS cost of 26000 seems might higher than GENERAL_REGS cost. > > It does not matter what class IRA gives the address reg. LRA should fix this > anyway. For usual memory the correct address reg class is checked by > legitimate_address_p hook. > > I guess in this case it is a special memory and its constraint does not > check address reg class at all. I believe the bug should be fixed on > machine-dependent side of GCC (in constraints and predicates). In (define_predicate "bcst_mem_operand" (and (match_code "vec_duplicate") (and (match_test "TARGET_AVX512F") (ior (match_test "TARGET_AVX512VL") (match_test "GET_MODE_SIZE (GET_MODE (op)) == 64"))) (match_test "VALID_BCST_MODE_P (GET_MODE_INNER (GET_MODE (op)))") (match_test "memory_operand (XEXP (op, 0), GET_MODE (XEXP (op, 0)))"))) Shouldn't memory_operand (XEXP (op, 0), GET_MODE (XEXP (op, 0))) imply legitimate_address_p?
[Bug target/97532] [11 Regression] Error: insn does not satisfy its constraints, internal compiler error: in extract_constrain_insn, at recog.c:2196
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97532 --- Comment #5 from Jakub Jelinek --- The operand in this case is the whole (vec_duplicate:V8DF (mem:DF (reg...) [6 *fact_18(D)+0 S8 A64])) which matches the (define_special_memory_constraint "Br" "@internal bcst memory operand." (match_operand 0 "bcst_mem_operand")) constraint where bcst_mem_operand is: (define_predicate "bcst_mem_operand" (and (match_code "vec_duplicate") (and (match_test "TARGET_AVX512F") (ior (match_test "TARGET_AVX512VL") (match_test "GET_MODE_SIZE (GET_MODE (op)) == 64"))) (match_test "VALID_BCST_MODE_P (GET_MODE_INNER (GET_MODE (op)))") (match_test "memory_operand (XEXP (op, 0), GET_MODE (XEXP (op, 0)))"))) I think the extract_mem_from_operand function has been introduced for this in LRA, but perhaps it is not used in all the places where it is needed.
[Bug target/97532] [11 Regression] Error: insn does not satisfy its constraints, internal compiler error: in extract_constrain_insn, at recog.c:2196
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97532 --- Comment #4 from Vladimir Makarov --- (In reply to Jakub Jelinek from comment #3) > The IRA dump says: > a2(r189,l0) costs: AREG:2000,2000 DREG:2000,2000 CREG:26000,-1000 > BREG:2000,2000 SIREG:2000,2000 DIREG:2000,2000 AD_REGS:2000,2000 > CLOBBERED_REGS > :2000,2000 Q_REGS:2000,2000 TLS_GOTBASE_REGS:2000,2000 > GENERAL_REGS:2000,2000 SSE_FIRST_REG:12000,12000 NO_REX_SSE_REGS:12000,12000 > SSE_REGS:12000, > 12000 ALL_SSE_REGS:12000,12000 MMX_REGS:26000,26000 INT_SSE_REGS:26000,26000 > ALL_REGS:424000,424000 MEM:12000,12000 > so the INT_SSE_REGS cost of 26000 seems might higher than GENERAL_REGS cost. It does not matter what class IRA gives the address reg. LRA should fix this anyway. For usual memory the correct address reg class is checked by legitimate_address_p hook. I guess in this case it is a special memory and its constraint does not check address reg class at all. I believe the bug should be fixed on machine-dependent side of GCC (in constraints and predicates).
[Bug target/97532] [11 Regression] Error: insn does not satisfy its constraints, internal compiler error: in extract_constrain_insn, at recog.c:2196
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97532 --- Comment #3 from Jakub Jelinek --- The IRA dump says: a2(r189,l0) costs: AREG:2000,2000 DREG:2000,2000 CREG:26000,-1000 BREG:2000,2000 SIREG:2000,2000 DIREG:2000,2000 AD_REGS:2000,2000 CLOBBERED_REGS :2000,2000 Q_REGS:2000,2000 TLS_GOTBASE_REGS:2000,2000 GENERAL_REGS:2000,2000 SSE_FIRST_REG:12000,12000 NO_REX_SSE_REGS:12000,12000 SSE_REGS:12000, 12000 ALL_SSE_REGS:12000,12000 MMX_REGS:26000,26000 INT_SSE_REGS:26000,26000 ALL_REGS:424000,424000 MEM:12000,12000 so the INT_SSE_REGS cost of 26000 seems might higher than GENERAL_REGS cost.
[Bug target/97532] [11 Regression] Error: insn does not satisfy its constraints, internal compiler error: in extract_constrain_insn, at recog.c:2196
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97532
Jakub Jelinek changed:
What|Removed |Added
CC||liuhongt at gcc dot gnu.org,
||vmakarov at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
Started with r11-4203-g7026bb9504eb0f95e114f832cd6dd14302376861
We have:
(insn 87 4 5 2 (set (reg:DI 189)
(reg:DI 2 cx [ fact ])) "simd-2.f90":13:0 74 {*movdi_internal}
(expr_list:REG_DEAD (reg:DI 2 cx [ fact ])
(nil)))
...
(insn 76 75 81 2 (set (reg:V8DF 153 [ vect_c_20.334 ])
(plus:V8DF (vec_duplicate:V8DF (mem:DF (reg:DI 189) [6 *fact_18(D)+0 S8
A64]))
(reg:V8DF 184 [ vect__17.333 ]))) "simd-2.f90":18:0 1569
{*addv8df3}
(expr_list:REG_DEAD (reg:DI 189)
(expr_list:REG_DEAD (reg:V8DF 184 [ vect__17.333 ])
(nil
as the only insns that refer to pseudo 189, and for some reason IRA decides to
allocate that pseudo into xmm4 register which is not valid for memory
addresses.
So, something in the r11-4202 IRA changes doesn't work properly (and maybe
something in LRA too, because even if IRA decides to put it into such register,
which it e.g. could because 95% of uses would be in vector register contexts,
LRA should be able to fix it up, shouldn't it?
[Bug target/97532] [11 Regression] Error: insn does not satisfy its constraints, internal compiler error: in extract_constrain_insn, at recog.c:2196
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97532 Richard Biener changed: What|Removed |Added Summary|Error: insn does not|[11 Regression] Error: insn |satisfy its constraints,|does not satisfy its |internal compiler error: in |constraints, internal |extract_constrain_insn, at |compiler error: in |recog.c:2196|extract_constrain_insn, at ||recog.c:2196 Last reconfirmed||2020-10-22 Target Milestone|--- |11.0 Status|UNCONFIRMED |NEW Target||x86_64-*-* i?86-*-* Ever confirmed|0 |1 Component|libgomp |target --- Comment #1 from Richard Biener --- Confirmed.
