> 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
