* [Bug target/100736] ICE: unrecognizable insn
2021-05-24 6:04 [Bug target/100736] New: ICE: unrecognizable insn asolokha at gmx dot com
@ 2021-06-03 0:11 ` segher at gcc dot gnu.org
2021-12-08 7:17 ` guihaoc at gcc dot gnu.org
` (5 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: segher at gcc dot gnu.org @ 2021-06-03 0:11 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug target/100736] ICE: unrecognizable insn
2021-05-24 6:04 [Bug target/100736] New: ICE: unrecognizable insn asolokha at gmx dot com
2021-06-03 0:11 ` [Bug target/100736] " segher at gcc dot gnu.org
@ 2021-12-08 7:17 ` guihaoc at gcc dot gnu.org
2021-12-08 22:13 ` segher at gcc dot gnu.org
` (4 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: guihaoc at gcc dot gnu.org @ 2021-12-08 7:17 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug target/100736] ICE: unrecognizable insn
2021-05-24 6:04 [Bug target/100736] New: ICE: unrecognizable insn asolokha at gmx dot com
2021-06-03 0:11 ` [Bug target/100736] " segher at gcc dot gnu.org
2021-12-08 7:17 ` guihaoc at gcc dot gnu.org
@ 2021-12-08 22:13 ` segher at gcc dot gnu.org
2021-12-09 1:49 ` guihaoc at gcc dot gnu.org
` (3 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: segher at gcc dot gnu.org @ 2021-12-08 22:13 UTC (permalink / raw)
To: gcc-bugs
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 :-)
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug target/100736] ICE: unrecognizable insn
2021-05-24 6:04 [Bug target/100736] New: ICE: unrecognizable insn asolokha at gmx dot com
` (2 preceding siblings ...)
2021-12-08 22:13 ` segher at gcc dot gnu.org
@ 2021-12-09 1:49 ` guihaoc at gcc dot gnu.org
2022-08-24 3:57 ` bergner at gcc dot gnu.org
` (2 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: guihaoc at gcc dot gnu.org @ 2021-12-09 1:49 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug target/100736] ICE: unrecognizable insn
2021-05-24 6:04 [Bug target/100736] New: ICE: unrecognizable insn asolokha at gmx dot com
` (3 preceding siblings ...)
2021-12-09 1:49 ` guihaoc at gcc dot gnu.org
@ 2022-08-24 3:57 ` bergner at gcc dot gnu.org
2022-08-24 20:45 ` segher at gcc dot gnu.org
2024-04-23 5:37 ` guojiufu at gcc dot gnu.org
6 siblings, 0 replies; 8+ messages in thread
From: bergner at gcc dot gnu.org @ 2022-08-24 3:57 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug target/100736] ICE: unrecognizable insn
2021-05-24 6:04 [Bug target/100736] New: ICE: unrecognizable insn asolokha at gmx dot com
` (4 preceding siblings ...)
2022-08-24 3:57 ` bergner at gcc dot gnu.org
@ 2022-08-24 20:45 ` segher at gcc dot gnu.org
2024-04-23 5:37 ` guojiufu at gcc dot gnu.org
6 siblings, 0 replies; 8+ messages in thread
From: segher at gcc dot gnu.org @ 2022-08-24 20:45 UTC (permalink / raw)
To: gcc-bugs
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!)
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug target/100736] ICE: unrecognizable insn
2021-05-24 6:04 [Bug target/100736] New: ICE: unrecognizable insn asolokha at gmx dot com
` (5 preceding siblings ...)
2022-08-24 20:45 ` segher at gcc dot gnu.org
@ 2024-04-23 5:37 ` guojiufu at gcc dot gnu.org
6 siblings, 0 replies; 8+ messages in thread
From: guojiufu at gcc dot gnu.org @ 2024-04-23 5:37 UTC (permalink / raw)
To: gcc-bugs
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. ***
^ permalink raw reply [flat|nested] 8+ messages in thread