[Bug target/100418] [12 Regression][gcn] since r12-397 bootstrap fails: error: unrecognizable insn: in extract_insn, at recog.c:2770
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100418 Andrew Stubbs changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #17 from Andrew Stubbs --- This issue should be fixed now.
[Bug target/100418] [12 Regression][gcn] since r12-397 bootstrap fails: error: unrecognizable insn: in extract_insn, at recog.c:2770
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100418 --- Comment #16 from CVS Commits --- The master branch has been updated by Andrew Stubbs : https://gcc.gnu.org/g:07d7d37d1a33efb04f1262e56f4b82d6e1089e75 commit r12-632-g07d7d37d1a33efb04f1262e56f4b82d6e1089e75 Author: Andrew Stubbs Date: Fri May 7 15:31:05 2021 +0100 Ensure emit_move_insn operands are valid Some architectures are fine with PLUS in move instructions, but others are not (amdgcn is the motivating example). 2021-05-07 Jakub Jelinek Andrew Stubbs gcc/ChangeLog: PR target/100418 * builtins.c (try_store_by_multiple_pieces): Use force_operand for emit_move_insn operands.
[Bug target/100418] [12 Regression][gcn] since r12-397 bootstrap fails: error: unrecognizable insn: in extract_insn, at recog.c:2770
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100418 --- Comment #15 from David Binderman --- (In reply to Jakub Jelinek from comment #14) > This PR is about amdgcn ICEs, so please move x86 related ICEs to a different > PR, they have nothing to do with this bug. Done. Please see # 100445.
[Bug target/100418] [12 Regression][gcn] since r12-397 bootstrap fails: error: unrecognizable insn: in extract_insn, at recog.c:2770
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100418 --- Comment #14 from Jakub Jelinek --- This PR is about amdgcn ICEs, so please move x86 related ICEs to a different PR, they have nothing to do with this bug.
[Bug target/100418] [12 Regression][gcn] since r12-397 bootstrap fails: error: unrecognizable insn: in extract_insn, at recog.c:2770
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100418 --- Comment #13 from Andrew Stubbs --- I found a lot more ICEs when testing my patch. They look to be unrelated (TImode come back to haunt us), but it makes it hard to be sure.
[Bug target/100418] [12 Regression][gcn] since r12-397 bootstrap fails: error: unrecognizable insn: in extract_insn, at recog.c:2770
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100418 --- Comment #12 from David Binderman --- It looks like my ice is due to commit f3661f2d63fbc5fd30c24d22137691e16b0a0a17 by Uroš Bizjak. I'll send in another bug report. Sorry for this mixup.
[Bug target/100418] [12 Regression][gcn] since r12-397 bootstrap fails: error: unrecognizable insn: in extract_insn, at recog.c:2770
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100418 --- Comment #11 from Tobias Burnus --- (In reply to David Binderman from comment #10) > Reduced C code: [...] > $ /home/dcb/gcc/results/bin/gcc -c -w -O3 -march=bdver2 bug716.c Compiles here without an ICE. Additionally, are you sure that that's for the right PR? Commit r12-397 is about memset. Note: 'extract_insn, at recog.c:2770' is a generic issue - it shows up in emit_insn when no insn for that target can be found. There can be various causes for the latter - and, unless the reviewer likes my late-stage, catch-all patch (*), it likely requires a separate fix. (*) https://gcc.gnu.org/pipermail/gcc-patches/2021-May/569656.html In any case, it is unlikely be fixed by the more surgical alternative patch, which uses force_operand (→ comment 7, not (yet) submitted).
[Bug target/100418] [12 Regression][gcn] since r12-397 bootstrap fails: error: unrecognizable insn: in extract_insn, at recog.c:2770
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100418
--- Comment #10 from David Binderman ---
Reduced C code:
int kgd_get_dense_grid_point_double_mesh_mesh_i;
int kgd_get_dense_grid_point_double_mesh_mesh_address[3];
kgd_get_dense_grid_point_double_mesh_mesh() {
for (; kgd_get_dense_grid_point_double_mesh_mesh_i;
kgd_get_dense_grid_point_double_mesh_mesh_i++) {
kgd_get_dense_grid_point_double_mesh_mesh_address
[kgd_get_dense_grid_point_double_mesh_mesh_i] =
(kgd_get_dense_grid_point_double_mesh_mesh_i - 1) / 2;
}
get_grid_point_single_mesh(kgd_get_dense_grid_point_double_mesh_mesh_address);
}
$ /home/dcb/gcc/results/bin/gcc -c -w -O3 -march=bdver2 bug716.c
bug716.c: In function ‘kgd_get_dense_grid_point_double_mesh_mesh’:
bug716.c:11:1: error: unrecognizable insn:
11 | }
| ^
(insn 22 21 23 5 (set (reg:V2SI 95 [ vect_patt_5.16 ])
(if_then_else:V2SI (reg:V2SI 105)
(reg:V2SI 93 [ _40 ])
(reg:V2SI 94 [ vect__1.14 ]))) -1
(nil))
during RTL pass: vregs
bug716.c:11:1: internal compiler error: in extract_insn, at recog.c:2770
[Bug target/100418] [12 Regression][gcn] since r12-397 bootstrap fails: error: unrecognizable insn: in extract_insn, at recog.c:2770
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100418 --- Comment #9 from Andrew Stubbs --- I found a couple of other places to put force_operand and the full case works now. Running more tests
[Bug target/100418] [12 Regression][gcn] since r12-397 bootstrap fails: error: unrecognizable insn: in extract_insn, at recog.c:2770
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100418 --- Comment #8 from Jakub Jelinek --- That is weird. I think normally during expansion all the needed clobbers are added while expanding RTL, rather than waiting until the first pass that calls recog (that is during the vregs pass I think). The recog clobbers handling is there mainly for later RTL passes (like combiner).
[Bug target/100418] [12 Regression][gcn] since r12-397 bootstrap fails: error: unrecognizable insn: in extract_insn, at recog.c:2770
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100418 --- Comment #7 from Tobias Burnus --- (In reply to Jakub Jelinek from comment #5) > - emit_move_insn (rem, plus_constant (ptr_mode, rem, -blksize)); > + rtx rem_minus_blksize = plus_constant (ptr_mode, rem, -blksize); > + emit_move_insn (rem, force_operand (rem_minus_blksize, NULL_RTX)); Contrary to Andrew but for the full example it does not work here, at least assuming that I did not make a mistake. Namely, I still got: reshape_generic.c:355:1: error: unrecognizable insn: 355 | } | ^ (insn 545 544 546 45 (set (reg:DI 829) (plus:DI (reg:DI 829) (const_int -32 [0xffe0]))) "reshape_generic.c":186:14 -1 (nil)) during RTL pass: vregs * * * I think it should rather be something like the following - i.e. if there is a clobber, a parallel has to be added. The following seems to work fine when bootstrapping GCC: (Disclaimer: I don't know until when this is supposed to be called, I note that in lra.c, there is a note that insn_invalid_p shouldn't be called that late. Thus, it might need to be called after the late INSN changes in builtins.c but still before recog.c's extract_insn. But as it seems to work ...?) diff --git a/gcc/recog.c b/gcc/recog.c index eb617f11163..4ddc5d185af 100644 --- a/gcc/recog.c +++ b/gcc/recog.c @@ -2768,2 +2768,4 @@ extract_insn (rtx_insn *insn) icode = recog_memoized (insn); + if (icode < 0 && !insn_invalid_p (insn, false)) + icode = INSN_CODE (insn); if (icode < 0)
[Bug target/100418] [12 Regression][gcn] since r12-397 bootstrap fails: error: unrecognizable insn: in extract_insn, at recog.c:2770
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100418 Andrew Stubbs changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-05-05 Status|UNCONFIRMED |NEW --- Comment #6 from Andrew Stubbs --- Using force_operand does fix Tobias's reduced testcase. I'll test it further and let you know.
[Bug target/100418] [12 Regression][gcn] since r12-397 bootstrap fails: error: unrecognizable insn: in extract_insn, at recog.c:2770
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100418
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek ---
LRA uses for this kind of things emit_add2_insn.
This is during expansion though, and I think other spots e.g. in builtins.c use
in such cases
builtins.c- ret = plus_constant (GET_MODE (ret), ret, INTVAL
(len_rtx));
builtins.c: ret = emit_move_insn (target, force_operand (ret,
NULL_RTX));
instead, so I'd certainly try:
--- gcc/builtins.c.jj 2021-05-04 21:02:23.954802278 +0200
+++ gcc/builtins.c 2021-05-05 12:35:51.990008546 +0200
@@ -6775,7 +6775,8 @@ try_store_by_multiple_pieces (rtx to, rt
PTR+offset, we have to replace it. */
emit_move_insn (ptr, XEXP (to, 0));
to = replace_equiv_address (to, ptr);
- emit_move_insn (rem, plus_constant (ptr_mode, rem, -blksize));
+ rtx rem_minus_blksize = plus_constant (ptr_mode, rem, -blksize);
+ emit_move_insn (rem, force_operand (rem_minus_blksize, NULL_RTX));
}
/* Iterate over power-of-two block sizes from the maximum length to
@@ -6811,7 +6812,8 @@ try_store_by_multiple_pieces (rtx to, rt
{
emit_move_insn (ptr, XEXP (to, 0));
to = replace_equiv_address (to, ptr);
- emit_move_insn (rem, plus_constant (ptr_mode, rem, -blksize));
+ rtx rem_minus_blksize = plus_constant (ptr_mode, rem, -blksize);
+ emit_move_insn (rem, force_operand (rem_minus_blksize, NULL_RTX));
}
if (label)
[Bug target/100418] [12 Regression][gcn] since r12-397 bootstrap fails: error: unrecognizable insn: in extract_insn, at recog.c:2770
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100418 --- Comment #4 from Andrew Stubbs --- Alexandre's patch has this: emit_move_insn (rem, plus_constant (ptr_mode, rem, -blksize)); Is that generally a valid thing to do? It seems like other places do similar things...
[Bug target/100418] [12 Regression][gcn] since r12-397 bootstrap fails: error: unrecognizable insn: in extract_insn, at recog.c:2770
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100418 --- Comment #3 from Richard Biener --- I suspect the RTL generation in builtins.c is off somehow. Can you trace the insn to one of those?
[Bug target/100418] [12 Regression][gcn] since r12-397 bootstrap fails: error: unrecognizable insn: in extract_insn, at recog.c:2770
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100418
--- Comment #2 from Tobias Burnus ---
(gdb) p debug(x1)
(set (reg:DI 444)
(plus:DI (reg:DI 444)
(const_int -32 [0xffe0])))
Looking at the generated code, I see:
switch (GET_CODE (x4)) → (reg:DI 444)
case REG:
operands[1] = x4; → (reg:DI 444)
x6 = XEXP (x3, 1); → (const_int -32 [0xffe0])
operands[2] = x6;
switch (GET_CODE (operands[1]))
case REG:
switch (GET_MODE (operands[0])) → E_DImode
case E_DImode:
if (pnum_clobbers != NULL
&& register_operand (operands[0], E_DImode)
&& GET_MODE (x3) == E_DImode
&& register_operand (operands[1], E_DImode)
&& nonmemory_operand (operands[2], E_DImode))
{
*pnum_clobbers = 2;
return 29; /* adddi3 */
}
break;
Thus, we have three times the E_DImode – but 'pnum_clobbers' == NULL
as it is called via:
recog.c:
2768 icode = recog_memoized (insn);
→ rtl.h:
273 INSN_CODE (insn) = recog (PATTERN (insn), insn, 0);
→ insn-recog.c
recog (rtx x1 ATTRIBUTE_UNUSED,
rtx_insn *insn ATTRIBUTE_UNUSED,
int *pnum_clobbers ATTRIBUTE_UNUSED)
There 0 (for a nullptr) is passed → pnum_clobbers == NULL.
In gcn.md, the code for 'adddi3' is:
; Having this as an insn_and_split allows us to keep together DImode adds
; through some RTL optimisation passes, and means the CC reg we set isn't
; dependent on the constraint alternative (which doesn't seem to work well).
; If v_addc_u32 is used to add with carry, a 32-bit literal constant cannot be
; used as an operand due to the read of VCC, so we restrict constants to the
; inlinable range for that alternative.
(define_insn_and_split "adddi3"
[(set (match_operand:DI 0 "register_operand" "=Sg, v")
(plus:DI (match_operand:DI 1 "register_operand" " Sg, v")
(match_operand:DI 2 "nonmemory_operand" "SgB,vA")))
(clobber (match_scratch:BI 3 "=cs, X"))
(clobber (match_scratch:DI 4 "= X,cV"))]
I am not 100% sure, I understand where the 'pnum_clobbers != NULL' comes from,
but I think from:
acceptance_ptr->u.full.u.num_clobbers = XVECLEN (pattern, 0) - i;
in genrecog.c's remove_clobbers.
In any case, the define_insn_and_split does have two clobber ...
[Bug target/100418] [12 Regression][gcn] since r12-397 bootstrap fails: error: unrecognizable insn: in extract_insn, at recog.c:2770
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100418
Tobias Burnus changed:
What|Removed |Added
Target Milestone|--- |12.0
--- Comment #1 from Tobias Burnus ---
Reduced testcase - albeit with different missing insn:
./gcc/cc1 -O2 reshape_generic-17.i
extern _Noreturn void runtime_error (const char *, ...) ;
void reshape_internal (long int rdim)
{
long int shape_data[15];
int seen[15];
for (int n = 0; n < rdim; n++)
if (shape_data[n])
runtime_error("%ld", (long int) n+1);
long int v = 0;
for (int n = 0; n < rdim; n++)
seen[n] = 0;
if (seen[v] != 0)
runtime_error("");
}
reshape_generic-17.i: In function 'reshape_internal':
reshape_generic-17.i:14:1: error: unrecognizable insn:
14 | }
| ^
(insn 56 55 57 9 (set (reg:DI 446)
(plus:DI (reg:DI 446)
(const_int -32 [0xffe0]))) "reshape_generic-17.i":11:14
-1
(nil))
during RTL pass: vregs
reshape_generic-17.i:14:1: internal compiler error: in extract_insn, at
recog.c:2770
