Few more word around that: A rough analogy is that for SFmode, we still have a mov pattern (like movsf_softfloat) even without f/d extensions, instead of handling it via (subreg:SF (reg:SI)).
On Thu, Oct 23, 2025 at 2:52 PM Kito Cheng <[email protected]> wrote: > > On Thu, Oct 23, 2025 at 2:37 PM Robin Dapp <[email protected]> wrote: > > > > > It can be just use vfmv.v.f / vmv.v.x > > > > > >> /* Same for float, just that we can always handle 64-bit doubles > > >> even on !TARGET_64BIT. We have ruled out 16-bit HF already > > >> above. */ > > >> @@ -6220,6 +6224,10 @@ strided_broadcast_p (rtx op) > > >> if (!TARGET_ZVFH && mode == HFmode) > > >> return true; > > >> > > >> + /* We don't have a vfmv.bf16.v.f. */ > > >> + if (mode == BFmode) > > >> + return true; > > >> + > > > > > > and vfmv.v.f/vmv.v.x here > > > > Hmm, right, you mean punning with HImode again? Yeah, that would work and > > we > > could get rid of the strided fallback for that case. I'll do that in v2. > > It can be just put within BFmode should be fine, I mean > load/store/move/insert/extract could just use normal vector > instruction with SEW=16, > Only tha casting from/to other data types need real BF16 instruction. > ('real' might not be the right term to describe, but I guess you > should be able to get my point here :P) > > no casting to/from HImode, so that we can use the same pattern/logic > between w/ and w/o vector BF16 extension. > > And I think we won't ever have vfmv.bf16.v.f / vfmv.bf16.f.v since > they just play the exact same operation as vfmv.v.f / vfmv.f.v with > SEW=16. > > > > > > > -- > > Regards > > Robin > >
