Hi Robin,
Thanks a lot for taking the time to look at this, and no worries about
the delay.
On why I didn't introduce new modes: I reused the existing uint8/QImode
representation, following how FP8 is currently handled in the two places
I looked at:
- LLVM (llvm/llvm-project#191349): the OFP8 RVV vector types are
distinct Clang types but are lowered to plain i8 in LLVM IR -- no
new MVT.
- GCC AArch64 (FEAT_FP8): __mfp8 is make_unsigned_type (8) with QImode
(aarch64_init_fp8_types), and Mfloat8x8_t / Mfloat8x16_t map onto
V8QI / V16QI, the same modes as int8 vectors. The FP8 format is
selected at run time via the FPMR register, not encoded in the mode.
I agree the vtype/vsetvl handling is already involved. Since the altfmt
bit is just another VTYPE field (alongside vsew/vlmul/vta/vma), I
followed the existing ta/ma handling for it -- a numeric insn attribute
defaulting to INVALID_ATTRIBUTE, tracked and demanded by the vsetvl
pass.
On whether we expect a non-min Zvfofp8 with FMA or similar: I don't know
of any concrete plan. The only FP8 vector item in the RISC-V spec
database today is Zvfofp8min (RVS-3748, currently in Freeze), which is
conversion-only (FP8<->BF16 and FP32->FP8), and I don't see a fuller
Zvfofp8 proposed yet. That said, given the precedent of the minimal
extensions (e.g. Zfhmin / Zvfhmin alongside the full Zfh / Zvfh), it
seems plausible a fuller FP8 extension could follow later.
That's my reasoning for the current approach. I'm happy for you and the
maintainers to take the mode question up at the patchwork call, and I'll
go with whatever you decide.
Thanks again,
Lino
Robin Dapp <[email protected]> 於 2026年6月18日週四 下午5:09寫道：
>
> Hi Lino,
>
> Now, finally, found some time to look at the patches. Sorry for the very long
> delay.
>
> Without having yet looked into everything in detail, I wanted to address the
> elephant in the room which is the "altfmt" handling, obviously :)
>
> I'm not sure I really like having yet another insn attribute, the whole
> handling is complicated enough as it is. The uint8 reuse doesn't
> help understanding either. Also, do we expect a Zvfofp8 (non-min) extension
> at some point, offering FMA or similar?
>
> These three points lead me to a solution that specifies the two new modes
> explicitly, rather than reusing an existing mode and switching depending on a
> "bit". If we had those modes, we could derive the necessary
> properties directly from the mode, as we do for the other modes.
> So even though the modes wouldn't really be consumed by anything right now, I
> believe just having them would untangle things a bit. We could even continue
> hashing by name (that's not a significant issue in itself of course), and
> continue having a mode imply an extension.
>
> I'm aware that's no small ask but I'd imagine the short-term effort would
> outweigh long-term maintenance efforts.
>
> We'd still need vsetvl to carry the altfmt bit but as far as I can see it
> would
> vanish everywhere else and keep a bit more of the existing structure.
> Arguably, we wouldn't need new (float8) names for the conversion functions.
>
> Any particular reason why you opted against new modes? This might be
> something
> to discuss in the next patchwork call on Tuesday.
>
> --
> Regards
> Robin
>
