[Mlir-commits] [mlir] [MLIR] Add f8E8M0FNU type (PR #111028)

[Stella Laurenzo]

stellaraccident wrote:

> Yeah, we’re definitely dealing with a combinatorial explosion. For the compiler internals, have we thought about using a single FP type that models different E/M sizes and supports the required feature flags for the specific semantics of these formats? I wonder, though, if we need verification at some level (bindings?) to ensure compliance with the micro-scaling standard... Or do we want to leave the door open to arbitrary format? I'm not sure I fully understand the implications of the latter.

I can't defend my opinion rigorously, but I think that many of these "software only" types are leaking in from a well intentioned reading of the MX spec and an attempt to mirror that in MLIR. But the MX spec has very little to say about how the machines implement such things -- and the early state of implementations means that few of us fine purveyors of such machines are saying a lot of concrete details about the underlying implementations yet. My observation is that this has made it hard to plan the right level of support in MLIR, as the norm in this ecosystem is to work bottom up. But that is hard to do when the bottom is not defined in a way that everyone can see. And that is probably causing (again well-intentioned) premature generalization.

As Jakub says, many of these things are going to get defined in terms of conversion intrinsics (or emulation/helper functions) and a very small number of ways that they can actually interact with the hardware. I'd have to go dig through the original discussion on FP8, but a key point of that was that those types had a concrete realization in hardware and that the compiler was better off fully modeling such a thing (vs type punning, etc). I'm not sure that the same line of reasoning necessarily holds for all of these software/emulation variants.

But like I said, I'm not sure I can defend that position rigorously. In the absence of that, I think my core concern is that we may want a way in the code to better model software/emulated FP types.

https://github.com/llvm/llvm-project/pull/111028