Hi Lino, Now, finally, found some time to look at the patches. Sorry for the very long delay.
Without having yet looked into everything in detail, I wanted to address the elephant in the room which is the "altfmt" handling, obviously :) I'm not sure I really like having yet another insn attribute, the whole handling is complicated enough as it is. The uint8 reuse doesn't help understanding either. Also, do we expect a Zvfofp8 (non-min) extension at some point, offering FMA or similar? These three points lead me to a solution that specifies the two new modes explicitly, rather than reusing an existing mode and switching depending on a "bit". If we had those modes, we could derive the necessary properties directly from the mode, as we do for the other modes. So even though the modes wouldn't really be consumed by anything right now, I believe just having them would untangle things a bit. We could even continue hashing by name (that's not a significant issue in itself of course), and continue having a mode imply an extension. I'm aware that's no small ask but I'd imagine the short-term effort would outweigh long-term maintenance efforts. We'd still need vsetvl to carry the altfmt bit but as far as I can see it would vanish everywhere else and keep a bit more of the existing structure. Arguably, we wouldn't need new (float8) names for the conversion functions. Any particular reason why you opted against new modes? This might be something to discuss in the next patchwork call on Tuesday. -- Regards Robin
