[Bug target/100736] New: ICE: unrecognizable insn

[Bug target/100736] New: ICE: unrecognizable insn

[asolokha at gmx dot com]

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

            Bug ID: 100736
           Summary: ICE: unrecognizable insn
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Keywords: ice-on-valid-code
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: asolokha at gmx dot com
  Target Milestone: ---
            Target: powerpc-*-linux-gnu

gcc-12.0.0-alpha20210523 snapshot (g:c01c4331112aaf45f0de20ed8883dbeab83ed896)
ICEs when compiling the following testcase, reduced from
gcc/testsuite/gcc.target/powerpc/bcd-4.c, w/ -mvsx -mpower8-vector
-ffinite-math-only:

typedef __attribute__ ((altivec (vector__))) unsigned char v;

int
foo (v a, v b)
{
  return __builtin_vec_bcdsub_ge (a, b, 0);
}

% powerpc-e300c3-linux-gnu-gcc-12.0.0 -mvsx -mpower8-vector -ffinite-math-only
-c ktvdviry.c
ktvdviry.c: In function 'foo':
ktvdviry.c:7:1: error: unrecognizable insn:
    7 | }
      | ^
(insn 10 9 13 2 (set (reg:SI 119 [ _5 ])
        (ge:SI (reg:CCFP 106 6)
            (const_int 0 [0]))) "ktvdviry.c":6:10 -1
     (nil))
during RTL pass: vregs
ktvdviry.c:7:1: internal compiler error: in extract_insn, at recog.c:2770
0x6912fa _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.0_alpha20210523/work/gcc-12-20210523/gcc/rtl-error.c:108
0x69131a _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.0_alpha20210523/work/gcc-12-20210523/gcc/rtl-error.c:116
0x68f987 extract_insn(rtx_insn*)
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.0_alpha20210523/work/gcc-12-20210523/gcc/recog.c:2770
0xaf6de1 instantiate_virtual_regs_in_insn
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.0_alpha20210523/work/gcc-12-20210523/gcc/function.c:1609
0xaf6de1 instantiate_virtual_regs
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.0_alpha20210523/work/gcc-12-20210523/gcc/function.c:1983
0xaf6de1 execute
       
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.0_alpha20210523/work/gcc-12-20210523/gcc/function.c:2032

[Bug target/100736] ICE: unrecognizable insn

[segher at gcc dot gnu.org]

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

Segher Boessenkool <segher at gcc dot gnu.org> changed:

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

--- Comment #1 from Segher Boessenkool <segher at gcc dot gnu.org> ---
Confirmed.  Happens at expand time already.

[Bug target/100736] ICE: unrecognizable insn

[guihaoc at gcc dot gnu.org]

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

HaoChen Gui <guihaoc at gcc dot gnu.org> changed:

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

--- Comment #2 from HaoChen Gui <guihaoc at gcc dot gnu.org> ---
The root cause of the issue is condition rtx can't be recognized when
finite-math-only is set.
I drafted a patch to modify expand of "bcd<bcd_add_sub>_<code>_<mode>". It
expands as before when finite-math-only is not set. While it expands with a
reverse comparison(le -> ungt, ge -> unlt) when finite-math-only is set.
"rs6000_reverse_compare" is a helper method. The code is extracted from
"rs6000_emit_sCOND".
Any comments? Thanks a lot.

diff --git a/gcc/config/rs6000/altivec.md b/gcc/config/rs6000/altivec.md
index 93d237156d5..e91a1af6805 100644
--- a/gcc/config/rs6000/altivec.md
+++ b/gcc/config/rs6000/altivec.md
@@ -4415,7 +4415,7 @@ (define_insn "bcd<bcd_add_sub>_<mode>"
 ;; UNORDERED test on an integer type (like V1TImode) is not defined.  The type
 ;; probably should be one that can go in the VMX (Altivec) registers, so we
 ;; can't use DDmode or DFmode.
-(define_insn "*bcd<bcd_add_sub>_test_<mode>"
+(define_insn "bcd<bcd_add_sub>_test_<mode>"
   [(set (reg:CCFP CR6_REGNO)
        (compare:CCFP
         (unspec:V2DF [(match_operand:VBCD 1 "register_operand" "v")
@@ -4542,6 +4542,18 @@ (define_expand "bcd<bcd_add_sub>_<code>_<mode>"
   "TARGET_P8_VECTOR"
 {
   operands[4] = CONST0_RTX (V2DFmode);
+  emit_insn (gen_bcd<bcd_add_sub>_test_<mode> (operands[0], operands[1],
+                                              operands[2], operands[3],
+                                              operands[4]));
+  rtx cr6 = gen_rtx_REG (CCFPmode, CR6_REGNO);
+  rtx condition_rtx = gen_rtx_<CODE> (SImode, cr6, const0_rtx);
+  if (flag_finite_math_only)
+    {
+      condition_rtx = rs6000_reverse_compare (condition_rtx);
+      PUT_MODE (condition_rtx, SImode);
+    }
+  emit_insn (gen_rtx_SET (operands[0], condition_rtx));
+  DONE;
 })

 (define_insn "*bcdinvalid_<mode>"
diff --git a/gcc/config/rs6000/rs6000-protos.h
b/gcc/config/rs6000/rs6000-protos.h
index 14f6b313105..9b93e26bec2 100644
--- a/gcc/config/rs6000/rs6000-protos.h
+++ b/gcc/config/rs6000/rs6000-protos.h
@@ -114,6 +114,7 @@ extern enum rtx_code rs6000_reverse_condition
(machine_mode,
 extern rtx rs6000_emit_eqne (machine_mode, rtx, rtx, rtx);
 extern rtx rs6000_emit_fp_cror (rtx_code, machine_mode, rtx);
 extern void rs6000_emit_sCOND (machine_mode, rtx[]);
+extern rtx rs6000_reverse_compare (rtx);
 extern void rs6000_emit_cbranch (machine_mode, rtx[]);
 extern char * output_cbranch (rtx, const char *, int, rtx_insn *);
 extern const char * output_probe_stack_range (rtx, rtx, rtx);
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index ad860728169..39a36add08f 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -15690,19 +15690,14 @@ rs6000_emit_fp_cror (rtx_code code, machine_mode
mode, rtx x)
   return cc;
 }

-void
-rs6000_emit_sCOND (machine_mode mode, rtx operands[])
+rtx
+rs6000_reverse_compare (rtx condition_rtx)
 {
-  rtx condition_rtx = rs6000_generate_compare (operands[1], mode);
   rtx_code cond_code = GET_CODE (condition_rtx);
-
-  if (FLOAT_MODE_P (mode) && HONOR_NANS (mode)
-      && !(FLOAT128_VECTOR_P (mode) && !TARGET_FLOAT128_HW))
-    ;
-  else if (cond_code == NE
-          || cond_code == GE || cond_code == LE
-          || cond_code == GEU || cond_code == LEU
-          || cond_code == ORDERED || cond_code == UNGE || cond_code == UNLE)
+  if (cond_code == NE
+      || cond_code == GE || cond_code == LE
+      || cond_code == GEU || cond_code == LEU
+      || cond_code == ORDERED || cond_code == UNGE || cond_code == UNLE)
     {
       rtx not_result = gen_reg_rtx (CCEQmode);
       rtx not_op, rev_cond_rtx;
@@ -15716,6 +15711,19 @@ rs6000_emit_sCOND (machine_mode mode, rtx operands[])
       emit_insn (gen_rtx_SET (not_result, not_op));
       condition_rtx = gen_rtx_EQ (VOIDmode, not_result, const0_rtx);
     }
+  return condition_rtx;
+}
+
+void
+rs6000_emit_sCOND (machine_mode mode, rtx operands[])
+{
+  rtx condition_rtx = rs6000_generate_compare (operands[1], mode);
+
+  if (FLOAT_MODE_P (mode) && HONOR_NANS (mode)
+      && !(FLOAT128_VECTOR_P (mode) && !TARGET_FLOAT128_HW))
+  ;
+  else
+    condition_rtx = rs6000_reverse_compare (condition_rtx);

   machine_mode op_mode = GET_MODE (XEXP (operands[1], 0));
   if (op_mode == VOIDmode)

[Bug target/100736] ICE: unrecognizable insn

[segher at gcc dot gnu.org]

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

--- Comment #3 from Segher Boessenkool <segher at gcc dot gnu.org> ---
Send patches to gcc-patches@, please.  Or is there a question?  Ask that
question then, please :-)

[Bug target/100736] ICE: unrecognizable insn

[guihaoc at gcc dot gnu.org]

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

--- Comment #4 from HaoChen Gui <guihaoc at gcc dot gnu.org> ---
Yes, there is a question. With my patch, the test case generates following
assembly. Seems they have the same latency (cror vs. crnot). I wonder why we
need reverse the CR bit comparison when finite-math-only is set. Thanks.

without finite-math-only
        bcdsub. %v2,%v2,%v3,0
        cror 26,25,26
        mfcr %r3,2
        rlwinm %r3,%r3,27,1

with finite-math-only
        bcdsub. %v2,%v2,%v3,0
        crnot 26,24
        mfcr %r3,2
        rlwinm %r3,%r3,27,1

[Bug target/100736] ICE: unrecognizable insn

[bergner at gcc dot gnu.org]

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

--- Comment #5 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Segher Boessenkool from comment #3)
> Send patches to gcc-patches@, please.  Or is there a question?  Ask that
> question then, please :-)

Segher, do you have an answer for Hao Chen's question in Comment #4?

[Bug target/100736] ICE: unrecognizable insn

[segher at gcc dot gnu.org]

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

--- Comment #6 from Segher Boessenkool <segher at gcc dot gnu.org> ---
There are so many things here, it's hard to start.  Two big things:

Firstly, this is not floating point at all, so -ffinite-math-only should not
make any difference.  We currently abuse CCFP (in a non-safe way), this should
be fixed.

Secondly, -mcpu=power9 (to get isel) or -mcpu=power10 (to get setbc) are more
interesting.  What is the generated machine code for those?

More things:

crnot is needed to get the polarity of the result correct.  We could instead
do a xori 1 (or similar) on the eventual GPR.  If we do say a cror and a crnot
we should make this can be combined to a crnor (all 14 logic functions are
supported), but if the inversion is done in the GPR (with such a xori, say),
this is much harder to optimise.

If we are not interested in overflows, always one of LT GT EQ is set, so we
never need any crlogical insn here.

To be exact, this is whenever we have valid inputs: if there is output
overflow cr6.3 will be set as well, but still exactly one of cr6.0, cr6.1,
cr6.2 will be set.

But if there is an invalid *input* cr6 is set to 0b0001 always.  I don't think
we need to care here (otoh it isn't obvious how to best model it!)

[Bug target/100736] ICE: unrecognizable insn

[guojiufu at gcc dot gnu.org]

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

Jiu Fu Guo <guojiufu at gcc dot gnu.org> changed:

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

--- Comment #7 from Jiu Fu Guo <guojiufu at gcc dot gnu.org> ---
*** Bug 114786 has been marked as a duplicate of this bug. ***