Thanks for the feedback.
I understand the preference for static attributes, but the altfmt operand
approach follows the same pattern already used in the RISC-V backend for ta and
ma attributes. Here's the existing implementation for reference:
;; The tail policy op value.
(define_attr "ta" ""
(cond [(eq_attr "type" "vlde,vimov,vfmov,vext,vmiota,vfsqrt,vfrecp,...")
(symbol_ref "riscv_vector::get_ta(operands[5])")
...
(eq_attr "type" "vimuladd,vfmuladd")
(symbol_ref "riscv_vector::get_ta(operands[7])")]
(const_int INVALID_ATTRIBUTE)))
;; The mask policy op value.
(define_attr "ma" ""
(cond [(eq_attr "type" "vlde,vext,vmiota,vfsqrt,...")
(symbol_ref "riscv_vector::get_ma(operands[6])")
...
(eq_attr "type" "vimuladd,vfmuladd")
(symbol_ref "riscv_vector::get_ma(operands[8])")]
(const_int INVALID_ATTRIBUTE)))
As you can see, both ta and ma are propagated to the vsetvl pass by extracting
the operand value via helper functions (get_ta(), get_ma()), with the operand
index varying by instruction type. The altfmt attribute follows exactly this
same infrastructure pattern.
More importantly, splitting into separate insns is not feasible due to the
limited 32-bit encoding space. As the ldot/bdot proposal notes:
"Some instructions in this proposal use the vtype.altfmt field, originally
proposed as part of the Zvfbfa extension, to select the format of one or more
of the operands. This approach helps conserve the limited 32-bit encoding space
available to vector instructions."
For example, the single instruction vfqwdota.vv uses vtype.altfmt to select the
format of vs1:
# format of vs1 supplied by altfmt (0 E4M3, 1 E5M2)
vfqwdota.vv vd, vs2, vs1, vm # vd[0] += E4M3(vs2) dot vs1
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.
