On 6/23/25 7:07 PM, Kito Cheng wrote:
- riscv_vector::emit_vlmax_insn (code_for_pred_broadcast (<MODE>mode),
- riscv_vector::UNARY_OP, operands);
+ /* We cannot do anything with a Float16 mode apart from converting.
+ So convert to float, broadcast and truncate. */
+ if (TARGET_ZVFHMIN && !TARGET_ZVFH && <VEL>mode == HFmode)
+ {
+ rtx tmpsf = gen_reg_rtx (SFmode);
+ emit_insn (gen_extendhfsf2 (tmpsf, operands[1]));
+ poly_uint64 nunits = GET_MODE_NUNITS (<MODE>mode);
+ machine_mode vmodesf
+ = riscv_vector::get_vector_mode (SFmode, nunits).require ();
+ rtx tmp = gen_reg_rtx (vmodesf);
+ rtx ops[] = {tmp, tmpsf};
+ riscv_vector::emit_vlmax_insn (code_for_pred_broadcast (vmodesf),
+ riscv_vector::UNARY_OP, ops);
+ rtx ops2[] = {operands[0], tmp};
+ riscv_vector::emit_vlmax_insn (code_for_pred_trunc (vmodesf),
+ riscv_vector::UNARY_OP_FRM_DYN, ops2);
I disagree with this part especially the comment, vlse for HF vector
just a 16 bits load, and load does not really care about the data
format but size.
Hmm, we certainly can do a bit more. Don't have have fmacs defined on
HF and/or BF types through one of those obscure HF/BF extensions?
Also we can put HF in GPR rather than FPR for those splat/broadcast
patterns in theory.
In theory, yes. BUt I don't think any of the patterns in the backend
have constraints that would allow a GPR to hold a BF16 value.
Given the objections, clearly this shouldn't be committed until those
are resolved.
Jeff
