On Thu, Jul 10, 2025 at 5:31 PM Robin Dapp <rdapp....@gmail.com> wrote: > > >> diff --git a/gcc/config/riscv/vector.md b/gcc/config/riscv/vector.md > >> index 6753b01db59..866aaf1e8a0 100644 > >> --- a/gcc/config/riscv/vector.md > >> +++ b/gcc/config/riscv/vector.md > >> @@ -1580,8 +1580,27 @@ (define_insn_and_split "*vec_duplicate<mode>" > >> "&& 1" > >> [(const_int 0)] > >> { > >> - riscv_vector::emit_vlmax_insn (code_for_pred_broadcast (<MODE>mode), > >> - riscv_vector::UNARY_OP, operands); > >> + if (!strided_load_broadcast_p () > >> + && TARGET_ZVFHMIN && !TARGET_ZVFH && <VEL>mode == HFmode) > >> + { > >> + /* For Float16, load, convert to float, then broadcast and > >> + truncate. */ > >> + rtx tmpsf = gen_reg_rtx (SFmode); > >> + emit_insn (gen_extendhfsf2 (tmpsf, operands[1])); > >> + poly_uint64 nunits = GET_MODE_NUNITS (<MODE>mode); > > > > This could be HF -> HI (bitcast) then a HI pred_broadcast then bitcast > > back to a HF vector again, > > this could prevent us introducing trunc here, > > and I would prefer to improve this since RVA23 profile only mandatory > > Zvfhmin not Zvfh. > > Sure I can do the reinterpret way. But what's the issue about Zvfhmin?
Oh, I guess I didn't expand enough about my thought: I don't care that we have bad performance/bad code gen here if Zvfh is mandatory for RVA23 since that means not many people and core will fall into this code gen path. But RVA23 will go to this code gen patch, which means we will go this path for years until the next profile becomes the new baseline, so I think it worth spending time to improve that :) > > -- > Regards > Robin >