[Bug target/100418] New: [12 Regression][gcn] since r12-397 bootstrap fails: error: unrecognizable insn: in extract_insn, at recog.c:2770

[Bug target/100418] New: [12 Regression][gcn] since r12-397 bootstrap fails: error: unrecognizable insn: in extract_insn, at recog.c:2770

[burnus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100418

            Bug ID: 100418
           Summary: [12 Regression][gcn] since r12-397 bootstrap fails:
                    error: unrecognizable insn: in extract_insn, at
                    recog.c:2770
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Keywords: build, ice-on-valid-code
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: burnus at gcc dot gnu.org
                CC: ams at gcc dot gnu.org, aoliva at gcc dot gnu.org, doko at gcc dot gnu.org
  Target Milestone: ---
            Target: amdgcn-amdhsa

That's for building amdgcn-amdhsa

Works before commit r12-397-gda9e6e63d1ae22e530ec7baf59f6ed028bf05776
(introduce try store by multiple pieces).
Side note: that version does not compile and was fixed by the next
commit r12-398-g5fbe6a8e73b52c6ebc28b9111456226c1cda6472


Namely, the build fails with:

make[4]: Entering directory '$build/amdgcn-amdhsa/libgfortran'
libtool: compile:  $build/./gcc/xgcc -B$build/./gcc/
-B$install/amdgcn-amdhsa/bin/ -B$install/amdgcn-amdhsa/lib/ -isystem
$install/amdgcn-amdhsa/include -isystem $install/amdgcn-amdhsa/sys-include
-DHAVE_CONFIG_H -I. -I$src/libgfortran -iquote$src/libgfortran/io
-I$src/libgfortran/../gcc -I$src/libgfortran/../gcc/config -I../.././gcc
-I$src/libgfortran/../libgcc -I../libgcc -I$src/libgfortran/../libbacktrace
-I../libbacktrace -I../libbacktrace -std=gnu11 -Wall -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings
-Werror=implicit-function-declaration -Werror=vla -fcx-fortran-rules
-ffunction-sections -fdata-sections -g -O2 -MT reshape_generic.lo -MD -MP -MF
.deps/reshape_generic.Tpo -c $src/libgfortran/intrinsics/reshape_generic.c -o
reshape_generic.o
$src/libgfortran/intrinsics/reshape_generic.c: In function 'reshape_internal':
$src/libgfortran/intrinsics/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 [0xffffffffffffffe0])))
"$src/libgfortran/intrinsics/reshape_generic.c":186:14 -1
     (nil))
during RTL pass: vregs
$src/libgfortran/intrinsics/reshape_generic.c:355: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

[burnus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100418

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |12.0

--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> ---
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 [0xffffffffffffffe0]))) "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

[Bug target/100418] [12 Regression][gcn] since r12-397 bootstrap fails: error: unrecognizable insn: in extract_insn, at recog.c:2770

[burnus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100418

--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(gdb) p debug(x1)
(set (reg:DI 444)
    (plus:DI (reg:DI 444)
        (const_int -32 [0xffffffffffffffe0])))

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 [0xffffffffffffffe0])
      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

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100418

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
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

[ams at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100418

--- Comment #4 from Andrew Stubbs <ams at gcc dot gnu.org> ---
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

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100418

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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

[ams at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100418

Andrew Stubbs <ams at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2021-05-05
             Status|UNCONFIRMED                 |NEW

--- Comment #6 from Andrew Stubbs <ams at gcc dot gnu.org> ---
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

[burnus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100418

--- Comment #7 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(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 [0xffffffffffffffe0]))) "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

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100418

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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

[ams at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100418

--- Comment #9 from Andrew Stubbs <ams at gcc dot gnu.org> ---
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

[dcb314 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100418

--- Comment #10 from David Binderman <dcb314 at hotmail dot com> ---
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

[burnus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100418

--- Comment #11 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(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

[dcb314 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100418

--- Comment #12 from David Binderman <dcb314 at hotmail dot com> ---
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

[ams at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100418

--- Comment #13 from Andrew Stubbs <ams at gcc dot gnu.org> ---
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

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100418

--- Comment #14 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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

[dcb314 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100418

--- Comment #15 from David Binderman <dcb314 at hotmail dot com> ---
(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

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100418

--- Comment #16 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Andrew Stubbs <ams@gcc.gnu.org>:

https://gcc.gnu.org/g:07d7d37d1a33efb04f1262e56f4b82d6e1089e75

commit r12-632-g07d7d37d1a33efb04f1262e56f4b82d6e1089e75
Author: Andrew Stubbs <ams@codesourcery.com>
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  <jakub@redhat.com>
                Andrew Stubbs  <amd@codesourcery.com>

    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

[ams at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100418

Andrew Stubbs <ams at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #17 from Andrew Stubbs <ams at gcc dot gnu.org> ---
This issue should be fixed now.