* [Bug c/111334] ICE is reported during the combine pass optimization
2023-09-08 3:17 [Bug c/111334] New: ICE is reported during the combine pass optimization chenglulu at loongson dot cn
@ 2023-09-08 3:20 ` chenglulu at loongson dot cn
2023-09-08 3:26 ` chenglulu at loongson dot cn
` (20 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: chenglulu at loongson dot cn @ 2023-09-08 3:20 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111334
--- Comment #1 from chenglulu <chenglulu at loongson dot cn> ---
$ gcc test.c -o - -S -O1
test.c: 在函数‘add_startpgm’中:
test.c:33:1: 编译器内部错误：在 simplify_subreg 中，于 simplify-rtx.cc:7538
33 | }
| ^
0x13506f4 simplify_context::simplify_subreg(machine_mode, rtx_def*,
machine_mode, poly_int<1u, unsigned long>)
/home/chenglulu/work/loongisa-toolchain/gcc-upstream/gcc/simplify-rtx.cc:7537
0x1351ea3 simplify_context::simplify_subreg(machine_mode, rtx_def*,
machine_mode, poly_int<1u, unsigned long>)
/home/chenglulu/work/loongisa-toolchain/gcc-upstream/gcc/simplify-rtx.cc:7787
0x135264c simplify_context::simplify_gen_subreg(machine_mode, rtx_def*,
machine_mode, poly_int<1u, unsigned long>)
/home/chenglulu/work/loongisa-toolchain/gcc-upstream/gcc/simplify-rtx.cc:7858
0xd1684f simplify_gen_subreg(machine_mode, rtx_def*, machine_mode, poly_int<1u,
unsigned long>)
/home/chenglulu/work/loongisa-toolchain/gcc-upstream/gcc/rtl.h:3549
0x1e4aa06 if_then_else_cond
/home/chenglulu/work/loongisa-toolchain/gcc-upstream/gcc/combine.cc:9400
0x1e4a21e if_then_else_cond
/home/chenglulu/work/loongisa-toolchain/gcc-upstream/gcc/combine.cc:9265
0x1e3ddb8 combine_simplify_rtx
/home/chenglulu/work/loongisa-toolchain/gcc-upstream/gcc/combine.cc:5748
0x1e3d79a subst
/home/chenglulu/work/loongisa-toolchain/gcc-upstream/gcc/combine.cc:5609
0x1e3df1f combine_simplify_rtx
/home/chenglulu/work/loongisa-toolchain/gcc-upstream/gcc/combine.cc:5769
0x1e3d79a subst
/home/chenglulu/work/loongisa-toolchain/gcc-upstream/gcc/combine.cc:5609
0x1e3d50d subst
/home/chenglulu/work/loongisa-toolchain/gcc-upstream/gcc/combine.cc:5536
0x1e35f40 try_combine
/home/chenglulu/work/loongisa-toolchain/gcc-upstream/gcc/combine.cc:3339
0x1e305a0 combine_instructions
/home/chenglulu/work/loongisa-toolchain/gcc-upstream/gcc/combine.cc:1285
0x1e5addb rest_of_handle_combine
/home/chenglulu/work/loongisa-toolchain/gcc-upstream/gcc/combine.cc:15063
0x1e5ae98 execute
/home/chenglulu/work/loongisa-toolchain/gcc-upstream/gcc/combine.cc:15107
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug c/111334] ICE is reported during the combine pass optimization
2023-09-08 3:17 [Bug c/111334] New: ICE is reported during the combine pass optimization chenglulu at loongson dot cn
2023-09-08 3:20 ` [Bug c/111334] " chenglulu at loongson dot cn
@ 2023-09-08 3:26 ` chenglulu at loongson dot cn
2023-09-08 3:52 ` chenglulu at loongson dot cn
` (19 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: chenglulu at loongson dot cn @ 2023-09-08 3:26 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111334
--- Comment #2 from chenglulu <chenglulu at loongson dot cn> ---
This problem occurred after adding the r14-3511 optimization.
However, during the debugging process, it was discovered that it was due to the
attempt to generate rtx during the combine pass optimization.
(set (reg:DI 124)
(zero_extend:DI (subreg:QI (umod:SI (reg:DI 122 [ reg ])
(ior:DI (if_then_else:DI (eq:DI (reg:DI 114)
(const_int 0 [0]))
(reg:DI 112)
(const_int 0 [0]))
(reg:DI 118))) 0)))
During the optimization process, the function simplify_context::simplify_subreg
will make the following judgments:
rtx
simplify_context::simplify_subreg (machine_mode outermode, rtx op,
machine_mode innermode, poly_uint64 byte)
{
/* Little bit of sanity checking. */
gcc_assert (innermode != VOIDmode);
gcc_assert (outermode != VOIDmode);
gcc_assert (innermode != BLKmode);
gcc_assert (outermode != BLKmode);
gcc_assert (GET_MODE (op) == innermode
|| GET_MODE (op) == VOIDmode);
...
op is (reg:DI 122 [ reg ]) but innermode is SI_mode,so wrong.
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug c/111334] ICE is reported during the combine pass optimization
2023-09-08 3:17 [Bug c/111334] New: ICE is reported during the combine pass optimization chenglulu at loongson dot cn
2023-09-08 3:20 ` [Bug c/111334] " chenglulu at loongson dot cn
2023-09-08 3:26 ` chenglulu at loongson dot cn
@ 2023-09-08 3:52 ` chenglulu at loongson dot cn
2023-09-08 3:58 ` [Bug target/111334] " pinskia at gcc dot gnu.org
` (18 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: chenglulu at loongson dot cn @ 2023-09-08 3:52 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111334
--- Comment #3 from chenglulu <chenglulu at loongson dot cn> ---
This involves the template <optab>di3_fake:
(define_insn "<optab>di3_fake"
[(set (match_operand:DI 0 "register_operand" "=r,&r,&r")
(sign_extend:DI
(any_div:SI (match_operand:DI 1 "register_operand" "r,r,0")
(match_operand:DI 2 "register_operand" "r,r,r"))))]
""
{
return loongarch_output_division ("<insn>.w<u>\t%0,%1,%2", operands);
}
[(set_attr "type" "idiv")
(set_attr "mode" "SI")
(set (attr "enabled")
(if_then_else
(match_test "!!which_alternative == loongarch_check_zero_div_p()")
(const_string "yes")
(const_string "no")))])
I think there is a problem with the implementation of this template.
First, the instructions generated in the template are [u]div.w[u], etc. The
description of such instructions in the instruction manual is that if the upper
32 bits are not extended by the 31st bit sign then the result is uncertain.
The second port, I don't know if the following is correct.
(any_div:SI (match_operand:DI 1 "register_operand" "r,r,0")
(match_operand:DI 2 "register_operand" "r,r,r"))))]
I try to modify this template：
(define_insn "<optab>di3_fake"
[(set (match_operand:DI 0 "register_operand" "=r,&r,&r")
(sign_extend:DI
(unspec:SI [(any_div:SI (match_operand:DI 1 "register_operand"
"r,r,0")
(match_operand:DI 2 "register_operand" "r,r,r"))]
UNSPEC_ANY_DIV)))]
""
{
return loongarch_output_division ("<insn>.w<u>\t%0,%1,%2", operands);
}
[(set_attr "type" "idiv")
(set_attr "mode" "SI")
(set (attr "enabled")
(if_then_else
(match_test "!!which_alternative == loongarch_check_zero_div_p()")
(const_string "yes")
(const_string "no")))])
This problem can be solved. But I don't know if what I'm doing is correct．．．
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug target/111334] ICE is reported during the combine pass optimization
2023-09-08 3:17 [Bug c/111334] New: ICE is reported during the combine pass optimization chenglulu at loongson dot cn
` (2 preceding siblings ...)
2023-09-08 3:52 ` chenglulu at loongson dot cn
@ 2023-09-08 3:58 ` pinskia at gcc dot gnu.org
2023-09-08 4:39 ` xry111 at gcc dot gnu.org
` (17 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-09-08 3:58 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111334
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|rtl-optimization |target
--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to chenglulu from comment #3)
> This involves the template <optab>di3_fake:
> (define_insn "<optab>di3_fake"
> [(set (match_operand:DI 0 "register_operand" "=r,&r,&r")
> (sign_extend:DI
> (any_div:SI (match_operand:DI 1 "register_operand" "r,r,0")
> (match_operand:DI 2 "register_operand" "r,r,r"))))]
That pattern definitely looks broken.
Divide's operands' mode must match the mode of the divide IIRC.
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug target/111334] ICE is reported during the combine pass optimization
2023-09-08 3:17 [Bug c/111334] New: ICE is reported during the combine pass optimization chenglulu at loongson dot cn
` (3 preceding siblings ...)
2023-09-08 3:58 ` [Bug target/111334] " pinskia at gcc dot gnu.org
@ 2023-09-08 4:39 ` xry111 at gcc dot gnu.org
2023-09-08 4:45 ` xry111 at gcc dot gnu.org
` (16 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: xry111 at gcc dot gnu.org @ 2023-09-08 4:39 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111334
Xi Ruoyao <xry111 at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed| |2023-09-08
--- Comment #5 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
(In reply to chenglulu from comment #3)
> This involves the template <optab>di3_fake:
> (define_insn "<optab>di3_fake"
> [(set (match_operand:DI 0 "register_operand" "=r,&r,&r")
> (sign_extend:DI
> (any_div:SI (match_operand:DI 1 "register_operand" "r,r,0")
> (match_operand:DI 2 "register_operand" "r,r,r"))))]
> ""
> {
> return loongarch_output_division ("<insn>.w<u>\t%0,%1,%2", operands);
> }
> [(set_attr "type" "idiv")
> (set_attr "mode" "SI")
> (set (attr "enabled")
> (if_then_else
> (match_test "!!which_alternative == loongarch_check_zero_div_p()")
> (const_string "yes")
> (const_string "no")))])
>
>
> I think there is a problem with the implementation of this template.
> First, the instructions generated in the template are [u]div.w[u], etc. The
> description of such instructions in the instruction manual is that if the
> upper 32 bits are not extended by the 31st bit sign then the result is
> uncertain.
I think this reason alone makes the pattern looks very wrong.
I'll take a look...
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug target/111334] ICE is reported during the combine pass optimization
2023-09-08 3:17 [Bug c/111334] New: ICE is reported during the combine pass optimization chenglulu at loongson dot cn
` (4 preceding siblings ...)
2023-09-08 4:39 ` xry111 at gcc dot gnu.org
@ 2023-09-08 4:45 ` xry111 at gcc dot gnu.org
2023-09-08 4:48 ` [Bug target/111334] [14 regression] " xry111 at gcc dot gnu.org
` (15 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: xry111 at gcc dot gnu.org @ 2023-09-08 4:45 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111334
--- Comment #6 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
(In reply to Xi Ruoyao from comment #5)
> (In reply to chenglulu from comment #3)
> > This involves the template <optab>di3_fake:
> > (define_insn "<optab>di3_fake"
> > [(set (match_operand:DI 0 "register_operand" "=r,&r,&r")
> > (sign_extend:DI
> > (any_div:SI (match_operand:DI 1 "register_operand" "r,r,0")
> > (match_operand:DI 2 "register_operand" "r,r,r"))))]
> > ""
> > {
> > return loongarch_output_division ("<insn>.w<u>\t%0,%1,%2", operands);
> > }
> > [(set_attr "type" "idiv")
> > (set_attr "mode" "SI")
> > (set (attr "enabled")
> > (if_then_else
> > (match_test "!!which_alternative == loongarch_check_zero_div_p()")
> > (const_string "yes")
> > (const_string "no")))])
> >
> >
> > I think there is a problem with the implementation of this template.
> > First, the instructions generated in the template are [u]div.w[u], etc. The
> > description of such instructions in the instruction manual is that if the
> > upper 32 bits are not extended by the 31st bit sign then the result is
> > uncertain.
>
> I think this reason alone makes the pattern looks very wrong.
>
> I'll take a look...
Hmm, I guess we should just make di3_fake an UNSPEC because there is no way to
use div.w and its friends out of <optab:any_div><mode>3.
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug target/111334] [14 regression] ICE is reported during the combine pass optimization
2023-09-08 3:17 [Bug c/111334] New: ICE is reported during the combine pass optimization chenglulu at loongson dot cn
` (5 preceding siblings ...)
2023-09-08 4:45 ` xry111 at gcc dot gnu.org
@ 2023-09-08 4:48 ` xry111 at gcc dot gnu.org
2023-09-08 6:02 ` chenglulu at loongson dot cn
` (14 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: xry111 at gcc dot gnu.org @ 2023-09-08 4:48 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111334
Xi Ruoyao <xry111 at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |14.0
Summary|ICE is reported during the |[14 regression] ICE is
|combine pass optimization |reported during the combine
| |pass optimization
Keywords| |ice-on-valid-code
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug target/111334] [14 regression] ICE is reported during the combine pass optimization
2023-09-08 3:17 [Bug c/111334] New: ICE is reported during the combine pass optimization chenglulu at loongson dot cn
` (6 preceding siblings ...)
2023-09-08 4:48 ` [Bug target/111334] [14 regression] " xry111 at gcc dot gnu.org
@ 2023-09-08 6:02 ` chenglulu at loongson dot cn
2023-09-08 6:18 ` chenglulu at loongson dot cn
` (13 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: chenglulu at loongson dot cn @ 2023-09-08 6:02 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111334
--- Comment #7 from chenglulu <chenglulu at loongson dot cn> ---
(In reply to Xi Ruoyao from comment #6)
> (In reply to Xi Ruoyao from comment #5)
> > (In reply to chenglulu from comment #3)
> > > This involves the template <optab>di3_fake:
> > > (define_insn "<optab>di3_fake"
> > > [(set (match_operand:DI 0 "register_operand" "=r,&r,&r")
> > > (sign_extend:DI
> > > (any_div:SI (match_operand:DI 1 "register_operand" "r,r,0")
> > > (match_operand:DI 2 "register_operand" "r,r,r"))))]
> > > ""
> > > {
> > > return loongarch_output_division ("<insn>.w<u>\t%0,%1,%2", operands);
> > > }
> > > [(set_attr "type" "idiv")
> > > (set_attr "mode" "SI")
> > > (set (attr "enabled")
> > > (if_then_else
> > > (match_test "!!which_alternative == loongarch_check_zero_div_p()")
> > > (const_string "yes")
> > > (const_string "no")))])
> > >
> > >
> > > I think there is a problem with the implementation of this template.
> > > First, the instructions generated in the template are [u]div.w[u], etc. The
> > > description of such instructions in the instruction manual is that if the
> > > upper 32 bits are not extended by the 31st bit sign then the result is
> > > uncertain.
> >
> > I think this reason alone makes the pattern looks very wrong.
> >
> > I'll take a look...
>
> Hmm, I guess we should just make di3_fake an UNSPEC because there is no way
> to use div.w and its friends out of <optab:any_div><mode>3.
I agree with your idea, so I tried changing it to something like this.Do you
think it's okay for me to change like this?
(define_insn "<optab>di3_fake"
[(set (match_operand:DI 0 "register_operand" "=r,&r,&r")
(sign_extend:DI
(unspec:SI [(any_div:SI (match_operand:DI 1 "register_operand"
"r,r,0")
(match_operand:DI 2 "register_operand" "r,r,r"))]
UNSPEC_ANY_DIV)))]
""
{
return loongarch_output_division ("<insn>.w<u>\t%0,%1,%2", operands);
}
[(set_attr "type" "idiv")
(set_attr "mode" "SI")
(set (attr "enabled")
(if_then_else
(match_test "!!which_alternative == loongarch_check_zero_div_p()")
(const_string "yes")
(const_string "no")))])
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug target/111334] [14 regression] ICE is reported during the combine pass optimization
2023-09-08 3:17 [Bug c/111334] New: ICE is reported during the combine pass optimization chenglulu at loongson dot cn
` (7 preceding siblings ...)
2023-09-08 6:02 ` chenglulu at loongson dot cn
@ 2023-09-08 6:18 ` chenglulu at loongson dot cn
2023-09-08 6:39 ` xry111 at gcc dot gnu.org
` (12 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: chenglulu at loongson dot cn @ 2023-09-08 6:18 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111334
--- Comment #8 from chenglulu <chenglulu at loongson dot cn> ---
(In reply to Andrew Pinski from comment #4)
> (In reply to chenglulu from comment #3)
> > This involves the template <optab>di3_fake:
> > (define_insn "<optab>di3_fake"
> > [(set (match_operand:DI 0 "register_operand" "=r,&r,&r")
> > (sign_extend:DI
> > (any_div:SI (match_operand:DI 1 "register_operand" "r,r,0")
> > (match_operand:DI 2 "register_operand" "r,r,r"))))]
>
> That pattern definitely looks broken.
> Divide's operands' mode must match the mode of the divide IIRC.
OK, thanks! So the compilation failure is caused by an error in this template,
right? （Sorry, I don't understand the optimization of this combine）
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug target/111334] [14 regression] ICE is reported during the combine pass optimization
2023-09-08 3:17 [Bug c/111334] New: ICE is reported during the combine pass optimization chenglulu at loongson dot cn
` (8 preceding siblings ...)
2023-09-08 6:18 ` chenglulu at loongson dot cn
@ 2023-09-08 6:39 ` xry111 at gcc dot gnu.org
2023-09-08 6:47 ` xry111 at gcc dot gnu.org
` (11 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: xry111 at gcc dot gnu.org @ 2023-09-08 6:39 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111334
--- Comment #9 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
(In reply to chenglulu from comment #7)
> (In reply to Xi Ruoyao from comment #6)
> > (In reply to Xi Ruoyao from comment #5)
> > > (In reply to chenglulu from comment #3)
> > > > This involves the template <optab>di3_fake:
> > > > (define_insn "<optab>di3_fake"
> > > > [(set (match_operand:DI 0 "register_operand" "=r,&r,&r")
> > > > (sign_extend:DI
> > > > (any_div:SI (match_operand:DI 1 "register_operand" "r,r,0")
> > > > (match_operand:DI 2 "register_operand" "r,r,r"))))]
> > > > ""
> > > > {
> > > > return loongarch_output_division ("<insn>.w<u>\t%0,%1,%2", operands);
> > > > }
> > > > [(set_attr "type" "idiv")
> > > > (set_attr "mode" "SI")
> > > > (set (attr "enabled")
> > > > (if_then_else
> > > > (match_test "!!which_alternative == loongarch_check_zero_div_p()")
> > > > (const_string "yes")
> > > > (const_string "no")))])
> > > >
> > > >
> > > > I think there is a problem with the implementation of this template.
> > > > First, the instructions generated in the template are [u]div.w[u], etc. The
> > > > description of such instructions in the instruction manual is that if the
> > > > upper 32 bits are not extended by the 31st bit sign then the result is
> > > > uncertain.
> > >
> > > I think this reason alone makes the pattern looks very wrong.
> > >
> > > I'll take a look...
> >
> > Hmm, I guess we should just make di3_fake an UNSPEC because there is no way
> > to use div.w and its friends out of <optab:any_div><mode>3.
>
> I agree with your idea, so I tried changing it to something like this.Do you
> think it's okay for me to change like this?
>
>
> (define_insn "<optab>di3_fake"
> [(set (match_operand:DI 0 "register_operand" "=r,&r,&r")
> (sign_extend:DI
> (unspec:SI [(any_div:SI (match_operand:DI 1 "register_operand"
> "r,r,0")
> (match_operand:DI 2 "register_operand" "r,r,r"))]
> UNSPEC_ANY_DIV)))]
> ""
> {
> return loongarch_output_division ("<insn>.w<u>\t%0,%1,%2", operands);
> }
> [(set_attr "type" "idiv")
> (set_attr "mode" "SI")
> (set (attr "enabled")
> (if_then_else
> (match_test "!!which_alternative == loongarch_check_zero_div_p()")
> (const_string "yes")
> (const_string "no")))])
I'm not sure if we can use a single UNSPEC_ANY_DIV value for 4 different
operations (I'm afraid it will make a further CSE pass believe "a % b" is same
as "a / b" but maybe I'm wrong here).
I came up with a more detailed template:
diff --git a/gcc/config/loongarch/loongarch.md
b/gcc/config/loongarch/loongarch.md
index 75f641b38ee..d162013695f 100644
--- a/gcc/config/loongarch/loongarch.md
+++ b/gcc/config/loongarch/loongarch.md
@@ -64,6 +64,9 @@ (define_c_enum "unspec" [
UNSPEC_CRC
UNSPEC_CRCC
+ ;; {div,mod}.w{,u} with bad input
+ UNSPEC_BAD_DIVW
+
UNSPEC_LOAD_FROM_GOT
UNSPEC_PCALAU12I
UNSPEC_ORI_L_LO12
@@ -880,7 +883,7 @@ (define_expand "<optab><mode>3"
(match_operand:GPR 2 "register_operand")))]
""
{
- if (GET_MODE (operands[0]) == SImode)
+ if (TARGET_64BIT && GET_MODE (operands[0]) == SImode)
{
rtx reg1 = gen_reg_rtx (DImode);
rtx reg2 = gen_reg_rtx (DImode);
@@ -917,10 +920,16 @@ (define_insn "*<optab><mode>3"
(define_insn "<optab>di3_fake"
[(set (match_operand:DI 0 "register_operand" "=r,&r,&r")
- (sign_extend:DI
- (any_div:SI (match_operand:DI 1 "register_operand" "r,r,0")
- (match_operand:DI 2 "register_operand" "r,r,r"))))]
- ""
+ (if_then_else
+ (and (eq (match_operand:DI 1 "register_operand" "r,r,0")
+ (sign_extend:DI (subreg:SI (match_dup 1) 0)))
+ (eq (match_operand:DI 2 "register_operand" "r,r,r")
+ (sign_extend:DI (subreg:SI (match_dup 2) 0))))
+ (sign_extend:DI
+ (any_div:SI (subreg:SI (match_dup 1) 0)
+ (subreg:SI (match_dup 2) 0)))
+ (unspec:DI [(const_int 0)] UNSPEC_BAD_DIVW)))]
+ "TARGET_64BIT"
{
return loongarch_output_division ("<insn>.w<u>\t%0,%1,%2", operands);
}
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug target/111334] [14 regression] ICE is reported during the combine pass optimization
2023-09-08 3:17 [Bug c/111334] New: ICE is reported during the combine pass optimization chenglulu at loongson dot cn
` (9 preceding siblings ...)
2023-09-08 6:39 ` xry111 at gcc dot gnu.org
@ 2023-09-08 6:47 ` xry111 at gcc dot gnu.org
2023-09-08 6:53 ` chenglulu at loongson dot cn
` (10 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: xry111 at gcc dot gnu.org @ 2023-09-08 6:47 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111334
--- Comment #10 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
(In reply to Xi Ruoyao from comment #9)
> (define_insn "<optab>di3_fake"
> [(set (match_operand:DI 0 "register_operand" "=r,&r,&r")
> - (sign_extend:DI
> - (any_div:SI (match_operand:DI 1 "register_operand" "r,r,0")
> - (match_operand:DI 2 "register_operand" "r,r,r"))))]
> - ""
> + (if_then_else
> + (and (eq (match_operand:DI 1 "register_operand" "r,r,0")
> + (sign_extend:DI (subreg:SI (match_dup 1) 0)))
> + (eq (match_operand:DI 2 "register_operand" "r,r,r")
> + (sign_extend:DI (subreg:SI (match_dup 2) 0))))
> + (sign_extend:DI
> + (any_div:SI (subreg:SI (match_dup 1) 0)
> + (subreg:SI (match_dup 2) 0)))
> + (unspec:DI [(const_int 0)] UNSPEC_BAD_DIVW)))]
With this the compiler will still believe all bad {div,mod}.w{,u} instructions
generate the exactly same unspecified value. But I don't think this is really
relevant: if a program depends on the unspecified value (no matter one value or
multiple values) it's already wrong.
If we are really "paranoid" about this we can make 4 UNSPEC_BAD_* constants and
use [(match_dup 1) (match_dup 2)] instead of [(const_int 0)].
> + "TARGET_64BIT"
> {
> return loongarch_output_division ("<insn>.w<u>\t%0,%1,%2", operands);
> }
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug target/111334] [14 regression] ICE is reported during the combine pass optimization
2023-09-08 3:17 [Bug c/111334] New: ICE is reported during the combine pass optimization chenglulu at loongson dot cn
` (10 preceding siblings ...)
2023-09-08 6:47 ` xry111 at gcc dot gnu.org
@ 2023-09-08 6:53 ` chenglulu at loongson dot cn
2023-09-08 6:58 ` xry111 at gcc dot gnu.org
` (9 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: chenglulu at loongson dot cn @ 2023-09-08 6:53 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111334
--- Comment #11 from chenglulu <chenglulu at loongson dot cn> ---
(In reply to Xi Ruoyao from comment #10)
> (In reply to Xi Ruoyao from comment #9)
>
> > (define_insn "<optab>di3_fake"
> > [(set (match_operand:DI 0 "register_operand" "=r,&r,&r")
> > - (sign_extend:DI
> > - (any_div:SI (match_operand:DI 1 "register_operand" "r,r,0")
> > - (match_operand:DI 2 "register_operand" "r,r,r"))))]
> > - ""
> > + (if_then_else
> > + (and (eq (match_operand:DI 1 "register_operand" "r,r,0")
> > + (sign_extend:DI (subreg:SI (match_dup 1) 0)))
> > + (eq (match_operand:DI 2 "register_operand" "r,r,r")
> > + (sign_extend:DI (subreg:SI (match_dup 2) 0))))
> > + (sign_extend:DI
> > + (any_div:SI (subreg:SI (match_dup 1) 0)
> > + (subreg:SI (match_dup 2) 0)))
> > + (unspec:DI [(const_int 0)] UNSPEC_BAD_DIVW)))]
>
> With this the compiler will still believe all bad {div,mod}.w{,u}
I think this is already defined as UNSPEC. Isn’t the simpler the logic, the
better?
> instructions generate the exactly same unspecified value. But I don't think
> this is really relevant: if a program depends on the unspecified value (no
> matter one value or multiple values) it's already wrong.
>
> If we are really "paranoid" about this we can make 4 UNSPEC_BAD_* constants
> and use [(match_dup 1) (match_dup 2)] instead of [(const_int 0)].
>
> > + "TARGET_64BIT"
> > {
> > return loongarch_output_division ("<insn>.w<u>\t%0,%1,%2", operands);
> > }
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug target/111334] [14 regression] ICE is reported during the combine pass optimization
2023-09-08 3:17 [Bug c/111334] New: ICE is reported during the combine pass optimization chenglulu at loongson dot cn
` (11 preceding siblings ...)
2023-09-08 6:53 ` chenglulu at loongson dot cn
@ 2023-09-08 6:58 ` xry111 at gcc dot gnu.org
2023-09-08 7:03 ` chenglulu at loongson dot cn
` (8 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: xry111 at gcc dot gnu.org @ 2023-09-08 6:58 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111334
--- Comment #12 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
(In reply to chenglulu from comment #11)
> (In reply to Xi Ruoyao from comment #10)
> > (In reply to Xi Ruoyao from comment #9)
> >
> > > (define_insn "<optab>di3_fake"
> > > [(set (match_operand:DI 0 "register_operand" "=r,&r,&r")
> > > - (sign_extend:DI
> > > - (any_div:SI (match_operand:DI 1 "register_operand" "r,r,0")
> > > - (match_operand:DI 2 "register_operand" "r,r,r"))))]
> > > - ""
> > > + (if_then_else
> > > + (and (eq (match_operand:DI 1 "register_operand" "r,r,0")
> > > + (sign_extend:DI (subreg:SI (match_dup 1) 0)))
> > > + (eq (match_operand:DI 2 "register_operand" "r,r,r")
> > > + (sign_extend:DI (subreg:SI (match_dup 2) 0))))
> > > + (sign_extend:DI
> > > + (any_div:SI (subreg:SI (match_dup 1) 0)
> > > + (subreg:SI (match_dup 2) 0)))
> > > + (unspec:DI [(const_int 0)] UNSPEC_BAD_DIVW)))]
> >
> > With this the compiler will still believe all bad {div,mod}.w{,u}
>
> I think this is already defined as UNSPEC. Isn’t the simpler the logic, the
> better?
Yes, I think we should just use 4 different UNSPEC_ values and the simple
version. But I've not find a way to use 4 different UNSPEC_ values in the RTL
template except duplicating everything 4 times...
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug target/111334] [14 regression] ICE is reported during the combine pass optimization
2023-09-08 3:17 [Bug c/111334] New: ICE is reported during the combine pass optimization chenglulu at loongson dot cn
` (12 preceding siblings ...)
2023-09-08 6:58 ` xry111 at gcc dot gnu.org
@ 2023-09-08 7:03 ` chenglulu at loongson dot cn
2023-09-08 7:04 ` xry111 at gcc dot gnu.org
` (7 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: chenglulu at loongson dot cn @ 2023-09-08 7:03 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111334
--- Comment #13 from chenglulu <chenglulu at loongson dot cn> ---
(In reply to Xi Ruoyao from comment #12)
> (In reply to chenglulu from comment #11)
> > (In reply to Xi Ruoyao from comment #10)
> > > (In reply to Xi Ruoyao from comment #9)
> > >
> > > > (define_insn "<optab>di3_fake"
> > > > [(set (match_operand:DI 0 "register_operand" "=r,&r,&r")
> > > > - (sign_extend:DI
> > > > - (any_div:SI (match_operand:DI 1 "register_operand" "r,r,0")
> > > > - (match_operand:DI 2 "register_operand" "r,r,r"))))]
> > > > - ""
> > > > + (if_then_else
> > > > + (and (eq (match_operand:DI 1 "register_operand" "r,r,0")
> > > > + (sign_extend:DI (subreg:SI (match_dup 1) 0)))
> > > > + (eq (match_operand:DI 2 "register_operand" "r,r,r")
> > > > + (sign_extend:DI (subreg:SI (match_dup 2) 0))))
> > > > + (sign_extend:DI
> > > > + (any_div:SI (subreg:SI (match_dup 1) 0)
> > > > + (subreg:SI (match_dup 2) 0)))
> > > > + (unspec:DI [(const_int 0)] UNSPEC_BAD_DIVW)))]
> > >
> > > With this the compiler will still believe all bad {div,mod}.w{,u}
> >
> > I think this is already defined as UNSPEC. Isn’t the simpler the logic, the
> > better?
>
> Yes, I think we should just use 4 different UNSPEC_ values and the simple
> version. But I've not find a way to use 4 different UNSPEC_ values in the
> RTL template except duplicating everything 4 times...
I still have a question that I don't quite understand, that is, why that the
four generated strings are equivalent when using an UNSPEC name? My template
names are different, and they will not be automatically matched during
optimization.???
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug target/111334] [14 regression] ICE is reported during the combine pass optimization
2023-09-08 3:17 [Bug c/111334] New: ICE is reported during the combine pass optimization chenglulu at loongson dot cn
` (13 preceding siblings ...)
2023-09-08 7:03 ` chenglulu at loongson dot cn
@ 2023-09-08 7:04 ` xry111 at gcc dot gnu.org
2023-09-08 7:16 ` xry111 at gcc dot gnu.org
` (6 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: xry111 at gcc dot gnu.org @ 2023-09-08 7:04 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111334
--- Comment #14 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
I'm trying
diff --git a/gcc/config/loongarch/loongarch.md
b/gcc/config/loongarch/loongarch.md
index 75f641b38ee..44d9b99b2f5 100644
--- a/gcc/config/loongarch/loongarch.md
+++ b/gcc/config/loongarch/loongarch.md
@@ -64,6 +64,12 @@ (define_c_enum "unspec" [
UNSPEC_CRC
UNSPEC_CRCC
+ ;; 32-bit divisions can produce unspecified value if TARGET_64BIT
+ UNSPEC_DIV_W
+ UNSPEC_UDIV_W
+ UNSPEC_MOD_W
+ UNSPEC_UMOD_W
+
UNSPEC_LOAD_FROM_GOT
UNSPEC_PCALAU12I
UNSPEC_ORI_L_LO12
@@ -461,6 +467,8 @@ (define_code_iterator neg_bitwise [and ior])
;; This code iterator allows unsigned and signed division to be generated
;; from the same template.
(define_code_iterator any_div [div udiv mod umod])
+(define_code_attr ANY_DIV [(div "DIV") (udiv "UDIV")
+ (mod "MOD") (umod "UMOD")])
;; This code iterator allows addition and subtraction to be generated
;; from the same template.
@@ -918,8 +926,9 @@ (define_insn "*<optab><mode>3"
(define_insn "<optab>di3_fake"
[(set (match_operand:DI 0 "register_operand" "=r,&r,&r")
(sign_extend:DI
- (any_div:SI (match_operand:DI 1 "register_operand" "r,r,0")
- (match_operand:DI 2 "register_operand" "r,r,r"))))]
+ (unspec:SI [(match_operand:DI 1 "register_operand" "r,r,0")
+ (match_operand:DI 2 "register_operand" "r,r,r")]
+ UNSPEC_<ANY_DIV>)))]
""
{
return loongarch_output_division ("<insn>.w<u>\t%0,%1,%2", operands);
But:
../../gcc/gcc/config/loongarch/loongarch.md:931:23: error: invalid decimal
constant "UNSPEC_<ANY_DIV>"
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug target/111334] [14 regression] ICE is reported during the combine pass optimization
2023-09-08 3:17 [Bug c/111334] New: ICE is reported during the combine pass optimization chenglulu at loongson dot cn
` (14 preceding siblings ...)
2023-09-08 7:04 ` xry111 at gcc dot gnu.org
@ 2023-09-08 7:16 ` xry111 at gcc dot gnu.org
2023-09-09 7:16 ` chenglulu at loongson dot cn
` (5 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: xry111 at gcc dot gnu.org @ 2023-09-08 7:16 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111334
--- Comment #15 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
(In reply to chenglulu from comment #13)
> (In reply to Xi Ruoyao from comment #12)
> > (In reply to chenglulu from comment #11)
> > > (In reply to Xi Ruoyao from comment #10)
> > > > (In reply to Xi Ruoyao from comment #9)
> > > >
> > > > > (define_insn "<optab>di3_fake"
> > > > > [(set (match_operand:DI 0 "register_operand" "=r,&r,&r")
> > > > > - (sign_extend:DI
> > > > > - (any_div:SI (match_operand:DI 1 "register_operand" "r,r,0")
> > > > > - (match_operand:DI 2 "register_operand" "r,r,r"))))]
> > > > > - ""
> > > > > + (if_then_else
> > > > > + (and (eq (match_operand:DI 1 "register_operand" "r,r,0")
> > > > > + (sign_extend:DI (subreg:SI (match_dup 1) 0)))
> > > > > + (eq (match_operand:DI 2 "register_operand" "r,r,r")
> > > > > + (sign_extend:DI (subreg:SI (match_dup 2) 0))))
> > > > > + (sign_extend:DI
> > > > > + (any_div:SI (subreg:SI (match_dup 1) 0)
> > > > > + (subreg:SI (match_dup 2) 0)))
> > > > > + (unspec:DI [(const_int 0)] UNSPEC_BAD_DIVW)))]
> > > >
> > > > With this the compiler will still believe all bad {div,mod}.w{,u}
> > >
> > > I think this is already defined as UNSPEC. Isn’t the simpler the logic, the
> > > better?
> >
> > Yes, I think we should just use 4 different UNSPEC_ values and the simple
> > version. But I've not find a way to use 4 different UNSPEC_ values in the
> > RTL template except duplicating everything 4 times...
>
> I still have a question that I don't quite understand, that is, why that the
> four generated strings are equivalent when using an UNSPEC name? My template
> names are different, and they will not be automatically matched during
> optimization.???
Oh I get it, you mean
(define_insn "<optab>di3_fake"
[(set (match_operand:DI 0 "register_operand" "=r,&r,&r")
(sign_extend:DI
- (any_div:SI (match_operand:DI 1 "register_operand" "r,r,0")
- (match_operand:DI 2 "register_operand" "r,r,r"))))]
+ (unspec:DI [(any_div:DI
+ (match_operand:DI 1 "register_operand" "r,r,0")
+ (match_operand:DI 2 "register_operand" "r,r,r"))]
+ UNSPEC_ANY_DIV)))]
""
{
return loongarch_output_division ("<insn>.w<u>\t%0,%1,%2", operands);
Good idea! I think it's better than my stupid hacks :).
I'd been thinking about:
(define_insn "<optab>di3_fake"
[(set (match_operand:DI 0 "register_operand" "=r,&r,&r")
(sign_extend:DI
- (any_div:SI (match_operand:DI 1 "register_operand" "r,r,0")
- (match_operand:DI 2 "register_operand" "r,r,r"))))]
+ (unspec:DI [(match_operand:DI 1 "register_operand" "r,r,0")
+ (match_operand:DI 2 "register_operand" "r,r,r")]
+ UNSPEC_ANY_DIV)))]
""
{
return loongarch_output_division ("<insn>.w<u>\t%0,%1,%2", operands);
and this is just wrong.
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug target/111334] [14 regression] ICE is reported during the combine pass optimization
2023-09-08 3:17 [Bug c/111334] New: ICE is reported during the combine pass optimization chenglulu at loongson dot cn
` (15 preceding siblings ...)
2023-09-08 7:16 ` xry111 at gcc dot gnu.org
@ 2023-09-09 7:16 ` chenglulu at loongson dot cn
2023-09-09 7:47 ` xry111 at gcc dot gnu.org
` (4 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: chenglulu at loongson dot cn @ 2023-09-09 7:16 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111334
--- Comment #16 from chenglulu <chenglulu at loongson dot cn> ---
(In reply to Xi Ruoyao from comment #15)
> (In reply to chenglulu from comment #13)
> > (In reply to Xi Ruoyao from comment #12)
> > > (In reply to chenglulu from comment #11)
> > > > (In reply to Xi Ruoyao from comment #10)
> > > > > (In reply to Xi Ruoyao from comment #9)
> > > > >
> > > > > > (define_insn "<optab>di3_fake"
> > > > > > [(set (match_operand:DI 0 "register_operand" "=r,&r,&r")
> > > > > > - (sign_extend:DI
> > > > > > - (any_div:SI (match_operand:DI 1 "register_operand" "r,r,0")
> > > > > > - (match_operand:DI 2 "register_operand" "r,r,r"))))]
> > > > > > - ""
> > > > > > + (if_then_else
> > > > > > + (and (eq (match_operand:DI 1 "register_operand" "r,r,0")
> > > > > > + (sign_extend:DI (subreg:SI (match_dup 1) 0)))
> > > > > > + (eq (match_operand:DI 2 "register_operand" "r,r,r")
> > > > > > + (sign_extend:DI (subreg:SI (match_dup 2) 0))))
> > > > > > + (sign_extend:DI
> > > > > > + (any_div:SI (subreg:SI (match_dup 1) 0)
> > > > > > + (subreg:SI (match_dup 2) 0)))
> > > > > > + (unspec:DI [(const_int 0)] UNSPEC_BAD_DIVW)))]
> > > > >
> > > > > With this the compiler will still believe all bad {div,mod}.w{,u}
> > > >
> > > > I think this is already defined as UNSPEC. Isn’t the simpler the logic, the
> > > > better?
> > >
> > > Yes, I think we should just use 4 different UNSPEC_ values and the simple
> > > version. But I've not find a way to use 4 different UNSPEC_ values in the
> > > RTL template except duplicating everything 4 times...
> >
> > I still have a question that I don't quite understand, that is, why that the
> > four generated strings are equivalent when using an UNSPEC name? My template
> > names are different, and they will not be automatically matched during
> > optimization.???
>
> Oh I get it, you mean
>
> (define_insn "<optab>di3_fake"
> [(set (match_operand:DI 0 "register_operand" "=r,&r,&r")
> (sign_extend:DI
> - (any_div:SI (match_operand:DI 1 "register_operand" "r,r,0")
> - (match_operand:DI 2 "register_operand" "r,r,r"))))]
> + (unspec:DI [(any_div:DI
> + (match_operand:DI 1 "register_operand" "r,r,0")
> + (match_operand:DI 2 "register_operand" "r,r,r"))]
> + UNSPEC_ANY_DIV)))]
> ""
> {
> return loongarch_output_division ("<insn>.w<u>\t%0,%1,%2", operands);
>
> Good idea! I think it's better than my stupid hacks :).
>
> I'd been thinking about:
>
> (define_insn "<optab>di3_fake"
> [(set (match_operand:DI 0 "register_operand" "=r,&r,&r")
> (sign_extend:DI
> - (any_div:SI (match_operand:DI 1 "register_operand" "r,r,0")
> - (match_operand:DI 2 "register_operand" "r,r,r"))))]
> + (unspec:DI [(match_operand:DI 1 "register_operand" "r,r,0")
> + (match_operand:DI 2 "register_operand" "r,r,r")]
> + UNSPEC_ANY_DIV)))]
> ""
> {
> return loongarch_output_division ("<insn>.w<u>\t%0,%1,%2", operands);
>
> and this is just wrong.
Is it better to modify it this way?
--- a/gcc/config/loongarch/loongarch.md
+++ b/gcc/config/loongarch/loongarch.md
@@ -60,6 +60,7 @@ (define_c_enum "unspec" [
;; Stack tie
UNSPEC_TIE
+ UNSPEC_ANY_DIV
;; CRC
UNSPEC_CRC
UNSPEC_CRCC
@@ -900,7 +901,7 @@ (define_expand "<optab><mode>3"
(match_operand:GPR 2 "register_operand")))]
""
{
- if (GET_MODE (operands[0]) == SImode)
+ if (GET_MODE (operands[0]) == SImode && TARGET_64BIT)
{
rtx reg1 = gen_reg_rtx (DImode);
rtx reg2 = gen_reg_rtx (DImode);
@@ -938,9 +939,12 @@ (define_insn "*<optab><mode>3"
(define_insn "<optab>di3_fake"
[(set (match_operand:DI 0 "register_operand" "=r,&r,&r")
(sign_extend:DI
- (any_div:SI (match_operand:DI 1 "register_operand" "r,r,0")
- (match_operand:DI 2 "register_operand" "r,r,r"))))]
- ""
+ (unspec:SI
+ [(subreg:SI
+ (any_div:DI (match_operand:DI 1 "register_operand" "r,r,0")
+ (match_operand:DI 2 "register_operand" "r,r,r")) 0)]
+ UNSPEC_ANY_DIV)))]
+ "TARGET_64BIT"
{
return loongarch_output_division ("<insn>.w<u>\t%0,%1,%2", operands);
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug target/111334] [14 regression] ICE is reported during the combine pass optimization
2023-09-08 3:17 [Bug c/111334] New: ICE is reported during the combine pass optimization chenglulu at loongson dot cn
` (16 preceding siblings ...)
2023-09-09 7:16 ` chenglulu at loongson dot cn
@ 2023-09-09 7:47 ` xry111 at gcc dot gnu.org
2023-09-09 8:24 ` chenglulu at loongson dot cn
` (3 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: xry111 at gcc dot gnu.org @ 2023-09-09 7:47 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111334
--- Comment #17 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
I think the proper description should be:
diff --git a/gcc/config/loongarch/loongarch.md
b/gcc/config/loongarch/loongarch.md
index 75f641b38ee..000d17b0ba6 100644
--- a/gcc/config/loongarch/loongarch.md
+++ b/gcc/config/loongarch/loongarch.md
@@ -64,6 +64,8 @@ (define_c_enum "unspec" [
UNSPEC_CRC
UNSPEC_CRCC
+ UNSPEC_DIV_W_OPERAND
+
UNSPEC_LOAD_FROM_GOT
UNSPEC_PCALAU12I
UNSPEC_ORI_L_LO12
@@ -892,7 +894,7 @@ (define_expand "<optab><mode>3"
emit_insn (gen_rtx_SET (reg1, operands[1]));
emit_insn (gen_rtx_SET (reg2, operands[2]));
- emit_insn (gen_<optab>di3_fake (rd, reg1, reg2));
+ emit_insn (gen_<optab>si3_extended (rd, reg1, reg2));
emit_insn (gen_rtx_SET (operands[0],
simplify_gen_subreg (SImode, rd, DImode, 0)));
DONE;
@@ -915,11 +917,14 @@ (define_insn "*<optab><mode>3"
(const_string "yes")
(const_string "no")))])
-(define_insn "<optab>di3_fake"
+(define_insn "<optab>si3_extended"
[(set (match_operand:DI 0 "register_operand" "=r,&r,&r")
(sign_extend:DI
- (any_div:SI (match_operand:DI 1 "register_operand" "r,r,0")
- (match_operand:DI 2 "register_operand" "r,r,r"))))]
+ (any_div:SI
+ (unspec:SI [(match_operand:DI 1 "register_operand" "r,r,0")]
+ UNSPEC_DIV_W_OPERAND)
+ (unspec:SI [(match_operand:DI 2 "register_operand" "r,r,r")]
+ UNSPEC_DIV_W_OPERAND))))]
""
{
return loongarch_output_division ("<insn>.w<u>\t%0,%1,%2", operands);
i. e. we define "UNSPEC_DIV_W_OPERAND" as a "machine-specific operation": if
the input is a sign-extended 32-bit value, the operation extracts the low
32-bit; otherwise, it produces random junks.
Note that the behavior actually depends on the values of operand[1] and
operands[2], not the result of operand[1] / operand[2]. So we should put
unspec inside any_div, not outside.
(I've not included the TARGET_64BIT change here, it should be done anyway.)
BTW is LA664 improved to handle non-properly-extended inputs with div.w?
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug target/111334] [14 regression] ICE is reported during the combine pass optimization
2023-09-08 3:17 [Bug c/111334] New: ICE is reported during the combine pass optimization chenglulu at loongson dot cn
` (17 preceding siblings ...)
2023-09-09 7:47 ` xry111 at gcc dot gnu.org
@ 2023-09-09 8:24 ` chenglulu at loongson dot cn
2023-09-09 9:52 ` xry111 at gcc dot gnu.org
` (2 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: chenglulu at loongson dot cn @ 2023-09-09 8:24 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111334
--- Comment #18 from chenglulu <chenglulu at loongson dot cn> ---
(In reply to Xi Ruoyao from comment #17)
> I think the proper description should be:
>
> diff --git a/gcc/config/loongarch/loongarch.md
> b/gcc/config/loongarch/loongarch.md
> index 75f641b38ee..000d17b0ba6 100644
> --- a/gcc/config/loongarch/loongarch.md
> +++ b/gcc/config/loongarch/loongarch.md
> @@ -64,6 +64,8 @@ (define_c_enum "unspec" [
> UNSPEC_CRC
> UNSPEC_CRCC
>
> + UNSPEC_DIV_W_OPERAND
> +
> UNSPEC_LOAD_FROM_GOT
> UNSPEC_PCALAU12I
> UNSPEC_ORI_L_LO12
> @@ -892,7 +894,7 @@ (define_expand "<optab><mode>3"
> emit_insn (gen_rtx_SET (reg1, operands[1]));
> emit_insn (gen_rtx_SET (reg2, operands[2]));
>
> - emit_insn (gen_<optab>di3_fake (rd, reg1, reg2));
> + emit_insn (gen_<optab>si3_extended (rd, reg1, reg2));
> emit_insn (gen_rtx_SET (operands[0],
> simplify_gen_subreg (SImode, rd, DImode, 0)));
> DONE;
> @@ -915,11 +917,14 @@ (define_insn "*<optab><mode>3"
> (const_string "yes")
> (const_string "no")))])
>
> -(define_insn "<optab>di3_fake"
> +(define_insn "<optab>si3_extended"
> [(set (match_operand:DI 0 "register_operand" "=r,&r,&r")
> (sign_extend:DI
> - (any_div:SI (match_operand:DI 1 "register_operand" "r,r,0")
> - (match_operand:DI 2 "register_operand" "r,r,r"))))]
> + (any_div:SI
> + (unspec:SI [(match_operand:DI 1 "register_operand" "r,r,0")]
> + UNSPEC_DIV_W_OPERAND)
> + (unspec:SI [(match_operand:DI 2 "register_operand" "r,r,r")]
> + UNSPEC_DIV_W_OPERAND))))]
> ""
> {
> return loongarch_output_division ("<insn>.w<u>\t%0,%1,%2", operands);
>
> i. e. we define "UNSPEC_DIV_W_OPERAND" as a "machine-specific operation": if
> the input is a sign-extended 32-bit value, the operation extracts the low
> 32-bit; otherwise, it produces random junks.
>
> Note that the behavior actually depends on the values of operand[1] and
> operands[2], not the result of operand[1] / operand[2]. So we should put
> unspec inside any_div, not outside.
>
> (I've not included the TARGET_64BIT change here, it should be done anyway.)
>
> BTW is LA664 improved to handle non-properly-extended inputs with div.w?
This problem has been fixed on LA664．
I don't quite understand why this operation is still needed in !TARGET_64BIT?
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug target/111334] [14 regression] ICE is reported during the combine pass optimization
2023-09-08 3:17 [Bug c/111334] New: ICE is reported during the combine pass optimization chenglulu at loongson dot cn
` (18 preceding siblings ...)
2023-09-09 8:24 ` chenglulu at loongson dot cn
@ 2023-09-09 9:52 ` xry111 at gcc dot gnu.org
2023-09-14 1:06 ` cvs-commit at gcc dot gnu.org
2023-09-14 1:17 ` chenglulu at loongson dot cn
21 siblings, 0 replies; 23+ messages in thread
From: xry111 at gcc dot gnu.org @ 2023-09-09 9:52 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111334
--- Comment #19 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
(In reply to chenglulu from comment #18)
> This problem has been fixed on LA664．
> I don't quite understand why this operation is still needed in !TARGET_64BIT?
It's not needed with !TARGET_64BIT. I just meant I didn't added TARGET_64BIT
because the diff was only for a quick discussion.
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug target/111334] [14 regression] ICE is reported during the combine pass optimization
2023-09-08 3:17 [Bug c/111334] New: ICE is reported during the combine pass optimization chenglulu at loongson dot cn
` (19 preceding siblings ...)
2023-09-09 9:52 ` xry111 at gcc dot gnu.org
@ 2023-09-14 1:06 ` cvs-commit at gcc dot gnu.org
2023-09-14 1:17 ` chenglulu at loongson dot cn
21 siblings, 0 replies; 23+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-09-14 1:06 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111334
--- Comment #20 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by LuluCheng <chenglulu@gcc.gnu.org>:
https://gcc.gnu.org/g:9a033b9feffc9d97d5acfe8ca3cd16359f4b714b
commit r14-3974-g9a033b9feffc9d97d5acfe8ca3cd16359f4b714b
Author: Lulu Cheng <chenglulu@loongson.cn>
Date: Mon Sep 11 16:20:29 2023 +0800
LoongArch: Fix bug of '<optab>di3_fake'.
PR target/111334
gcc/ChangeLog:
* config/loongarch/loongarch.md: Fix bug of '<optab>di3_fake'.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/pr111334.c: New test.
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug target/111334] [14 regression] ICE is reported during the combine pass optimization
2023-09-08 3:17 [Bug c/111334] New: ICE is reported during the combine pass optimization chenglulu at loongson dot cn
` (20 preceding siblings ...)
2023-09-14 1:06 ` cvs-commit at gcc dot gnu.org
@ 2023-09-14 1:17 ` chenglulu at loongson dot cn
21 siblings, 0 replies; 23+ messages in thread
From: chenglulu at loongson dot cn @ 2023-09-14 1:17 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111334
chenglulu <chenglulu at loongson dot cn> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #21 from chenglulu <chenglulu at loongson dot cn> ---
fixed
^ permalink raw reply [flat|nested] 23+ messages in thread