Thanks for the suggestion, but after further analysis I don't think static altfmt via separate insns is feasible in this case. The altfmt value is determined by the data type of vs1 (E4M3 vs E5M2), not by the intrinsic name or a compile-time constant parameter. However, GCC's type system only sees VQI_DOT mode for both — there is no distinct machine mode or RTL expression for E4M3 vs E5M2. The format distinction exists in the source-level vector types but is lost by the time we reach RTL. This is different from mul/mulu, where the signedness is explicit in the RTL via mult vs zero_extend. For vfqwdota.vv, both E4M3 and E5M2 variants produce identical RTL patterns, so the compiler cannot statically select between two define_insn patterns. Therefore, the only viable path is to pass the altfmt information from the vs1 source level down to the operand, and then propagate it from the operand to the vsetvl pass — which is exactly what the current patch does with get_altfmt(operands[N]).
> -----原始邮件----- > 发件人: "Robin Dapp" <[email protected]> > 发送时间:2026-07-06 21:08:56 (星期一) > 收件人: 覃珊珊 <[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 > > > Here vs2 is always E4M3, but vs1 can be either E4M3 (altfmt=0) or E5M2 > > (altfmt=1). Both variants share the same instruction encoding (funct6=0x26, > > funct3=1) — the only difference is the vtype.altfmt bit. If we were to > > assign > > separate encodings for every format variation of vs1, we would quickly > > exhaust the available opcode space. This is precisely why the architecture > > uses altfmt as a vtype state bit rather than distinct instruction encodings. > > > > To summarize: > > 1.The altfmt value is determined by the frontend at compile time, not an > > inherent property of the instruction itself. > > 2.Splitting into independent instructions would waste the limited 32-bit > > encoding space. > > 3.The get_altfmt() helper is infrastructure that supports both dynamic > > operand extraction and static fallback, consistent with how get_ta() and > > get_ma() already work. > > I'm not talking about changing the spec but about modelling two insns in gcc, > just like mul and mulu. Yes, these would still need a vtype-like switch in > vsetvl, but it could be static rather than operand dependent. Getting > tracking > information from operands is inherently brittle and we should avoid it > wherever > we can. > > ta/ma are different. We cannot encode their functionality in either mode or > instruction and besides, the ta/ma attributes in their current form are going > to go away anyway in the near future and will be integrated into a vector > predicate. > > -- > Regards > Robin
