I’ve got two points to chuck in here.
The first is that I raised the block-float question over in [RFC] Should the OCP microscaling float scalars be added to APFloat and FloatType? - #3 by krzysz00, where I observed that the sub-byte scalars of a blocked float are almost misleading as floats in that you’re not intended to arithmetic on them without an accompanying group scale, raising philosophical questions about whether they make sense as APFloat members. (And, though I didn’t mention it there, there’re also fixed-point types).
One observation I came to after posting that thread, but haven’t written up until now, is that my “do we want to extend APFloat?” vs. “a custom type is hard to work with” problem could be solved by opening up getIntOrFloatBitWidth(), the types usable in vector, and so on.
My preliminary thoughts on that are that we want to allow people to stick arbitrary semantic wrappers around N-bit integers and that any such wrapper would be allowable as a vector element, have a bitwidth, and so on.
We could potentially use MemRefElementTypeInterface for this - give it a std::optional<unsigned> getFixedBitWidth() … or, more realistically, a new interface that’d go something like
FixedWidthDataInterface {
unsigned getBitWidth();
APInt bitcastConstant(TypedAttribute);
}
to let you simply declare all these custom float types into existence.
(The lowering to LLVM here would be, I’m pretty sure, iN, discarding the semantic context, because I’d expect a lot of these types to be passed to platform-specific intrinsics or library functions)
The one problem with that approach is that these newtype wrappers are necessarily opaque to dialects like arith, so perhaps what we want is instead something along the lines of NumericTypeInterface either instead of or in addition to the ability to mark things as data with a width.
I’m not sure quite what the right solutions are here, but given how ML has a lot of custom numeric formats (… heck, it’s not just ML, if the set of data-like or numeric-like types was open, !posit.posit<N> could be a thing in a third-party library)
I hope these are somewhat useful thoughts.