Hi, Jeff.
I tried again:
+(define_expand "fma<mode>4"
+ [(parallel
+ [(set (match_operand:VF_AUTO 0 "register_operand")
+ (fma:VF_AUTO
+ (match_operand:VF_AUTO 1 "register_operand")
+ (match_operand:VF_AUTO 2 "register_operand")
+ (match_operand:VF_AUTO 3 "register_operand")))
+ (clobber (match_dup 4))])]
+ "TARGET_VECTOR"
+ {
+ operands[4] = gen_reg_rtx (Pmode);
+ })
+
+(define_insn_and_split "*fma<VF_AUTO:mode><P:mode>"
+ [(set (match_operand:VF_AUTO 0 "register_operand" "=vr, vr, ?&vr")
+ (fma:VF_AUTO
+ (match_operand:VF_AUTO 1 "register_operand" " %0, vr, vr")
+ (match_operand:VF_AUTO 2 "register_operand" " vr, vr, vr")
+ (match_operand:VF_AUTO 3 "register_operand" " vr, 0, vr")))
+ (clobber (match_operand:P 4 "register_operand" "=r,r,r"))]
+ "TARGET_VECTOR"
+ "#"
+ "&& reload_completed"
+ [(const_int 0)]
+ {
+ riscv_vector::emit_vlmax_vsetvl (<VF_AUTO:MODE>mode, operands[4]);
+ if (which_alternative == 2)
+ emit_insn (gen_rtx_SET (operands[0], operands[3]));
+ rtx ops[] = {operands[0], operands[1], operands[2], operands[3],
operands[0]};
+ riscv_vector::emit_vlmax_fp_ternary_insn (code_for_pred_mul (PLUS,
<VF_AUTO:MODE>mode),
+ riscv_vector::RVV_TERNOP, ops,
operands[4]);
+ DONE;
+ }
+ [(set_attr "type" "vfmuladd")
+ (set_attr "mode" "<VF_AUTO:MODE>")])
It seems to work and all test have passed.
Thanks for pointing this out.
I have sent V3:
https://gcc.gnu.org/pipermail/gcc-patches/2023-June/622481.html
If this implementation is more reasonable, I will send a separate patch to
adjust integer ternary autovec patterns.
[email protected]
From: Jeff Law
Date: 2023-06-21 23:32
To: 钟居哲; gcc-patches
CC: kito.cheng; kito.cheng; palmer; palmer; rdapp.gcc
Subject: Re: [PATCH] RISC-V: Support RVV floating-point ternary
auto-vectorization
On 6/21/23 09:28, 钟居哲 wrote:
> I have tried:
> (define_expand "fms<mode>4"
> [(parallel
> [(set (match_operand:VF_AUTO 0 "register_operand")
> (fma:VF_AUTO
> (match_operand:VF_AUTO 1 "register_operand")
> (match_operand:VF_AUTO 2 "register_operand")
> (neg:VF_AUTO
> (match_operand:VF_AUTO 3 "register_operand"))))
> (clobber (match_dup4))])]
> "TARGET_VECTOR"
> {
> operands[4] = gen_reg_rtx (Pmode);
> })
>
> (define_insn_and_split "*fms<VF_AUTO:mode><P:mode>"
> [(set (match_operand:VF_AUTO 0 "register_operand" "=vr, vr, ?&vr")
> (fma:VF_AUTO
> (match_operand:VF_AUTO 1 "register_operand" " %0, vr, vr")
> (match_operand:VF_AUTO 2 "register_operand" " vr, vr, vr")
> (neg:VF_AUTO
> (match_operand:VF_AUTO 3 "register_operand" " vr, 0, vr"))))
> (clobber (match_operand:P 4 "=r,r,r"))]
> "TARGET_VECTOR"
> "#"
> "&& reload_completed"
> [(const_int 0)]
> {
> riscv_vector::emit_vlmax_vsetvl (<MODE>mode, operands[4]);
> if (which_alternative == 2)
> emit_insn (gen_rtx_SET (operands[0], operands[3]));
> rtx ops[] = {operands[0], operands[1], operands[2], operands[3],
> operands[0]};
> riscv_vector::emit_vlmax_fp_ternary_insn (code_for_pred_mul (MINUS,
> <MODE>mode),
> riscv_vector::RVV_TERNOP, ops, operands[4]);
> DONE;
> }
> [(set_attr "type" "vfmuladd")
> (set_attr "mode" "<MODE>")])
>
> It fails and create ICE.
But where did ICE and *why*? That's really the question. Changing the
mode just looks like papering over a more serious issue.
jeff
