Sure. Here's a concrete example from the Zvfqwdota8f extension in the ldot/bdot
proposal:
Consider the vfqwdota.vv instruction:
vfqwdota.vv vd, vs2, vs1, vm
This single instruction computes a dot product where:
vs2 is always treated as E4M3 format
vs1 can be either E4M3 or E5M2, selected by the vtype.altfmt field
altfmt=0 → vs1 is E4M3
altfmt=1 → vs1 is E5M2
In the compiler's RTL, both variants use the same element mode (8-bit vectors,
e.g., RVVM1QI or equivalent), because the element width is identical. The mode
alone cannot distinguish whether vs1 is E4M3 or E5M2.
The problem for the vsetvl pass: When generating the vsetvli instruction that
precedes vfqwdota.vv, the pass must know which altfmt value to set. But since
both E4M3 and E5M2 variants share the same mode, the vsetvl pass cannot infer
altfmt from the mode alone. The explicit altfmt operand in the RTL pattern
carries this information from the .md file to the vsetvl pass.
Similarly, in the Zvqwdota8i extension:
vqwdotau.vv vd, vs2, vs1, vm
Here vs2 is always unsigned, but vs1 can be unsigned (altfmt=0) or signed
(altfmt=1). Again, both variants share the same 8-bit element mode, and the
vsetvl pass needs the altfmt operand to know which vtype configuration to emit.
This is why we need the altfmt operand even when the element mode is identical
— the mode captures width, but altfmt captures the format interpretation of a
specific operand that the vsetvl pass must know about.
> -----原始邮件-----
> 发件人: "Robin Dapp" <[email protected]>
> 发送时间:2026-07-01 15:10:19 (星期三)
> 收件人: 覃珊珊 <[email protected]>, "Robin Dapp" <[email protected]>
> 抄送: [email protected], [email protected], [email protected],
> [email protected], [email protected], [email protected]
> 主题: Re: [PATCH] RISC-V: Support altfmt attribute propagation to vsetvl pass
>
> > Thank you for the feedback.
> >
> > Yes, this is the same altfmt that Lino is proposing. This patch is intended
> > as
> > a complementary piece to Lino's work — providing the infrastructure to
> > propagate
> > the altfmt attribute through to the vsetvl pass, while Lino's patch focuses
> > on
> > defining the altfmt attribute itself.
> >
> > Regarding real modes: unfortunately we cannot always distinguish the format
> > purely
> > from the mode, because there are cases where the mode is the same but the
> > format
> > differs. For the specific details, please refer to:
> > https://github.com/aswaterman/riscv-misc/blob/main/isa/ldot-bdot/ldot-bdot.adoc
> >
> > In those cases, the element mode alone does not carry enough information
> > for the
> > vsetvl pass to make the correct decision, so we still need the explicit
> > altfmt
> > operand to disambiguate.
>
> Can you elaborate or give an example?
>
> --
> Regards
> Robin
