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?
