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
>
