> > 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.
>
> Just getting back to this now. I'm not sure I fully got it.
>
> Which instruction sequence do you have in mind for a BF broadcast?
>
> just e.g.
> vsetivli zero,8,e16,m1
> vfmv.v.f v2,f0?
>
> I somehow expected this to vill but if it works and is legal/safe, sure :)
vsetivli zero,8,e16,m1
vmv.v.x v2,t0
or
vsetivli zero,8,e16,m1
vfmv.v.f v2,f0
if zvfhmin available
But I realized we didn't implement that way on HF vector, that means
we might spend much more time to implement that on BF16,
So...I am OK with your current approach, we can improve that in future
once we have anyone who cares about this enough :P
Just explicitly say it again, LGTM to trunk :)
