Hi, just wanted to follow up on this. Please let me know if the example above clarifies the need for the altfmt propagation, or if there's anything else you'd like me to address. I look forward to your reply. Wishing you all the best.
> -----原始邮件----- > 发件人: 覃珊珊 <[email protected]> > 发送时间:2026-07-02 09:35:13 (星期四) > 收件人: "Robin Dapp" <[email protected]> > 抄送: [email protected], [email protected], [email protected], > [email protected], [email protected], [email protected] > 主题: Re: Re: [PATCH] RISC-V: Support altfmt attribute propagation to vsetvl > pass > > 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
