Document IREE's views on type support

[ScottTodd]

_{(In general, I think it would be useful to document more parts of IREE's compiler and runtime architecture)}

IREE aims to support a variety of frontends and backends, and uses a soup of MLIR dialects and passes to connect between them. Each layer of this aggregate system has its own views on types. Sometimes these views are explicit, such as through a spec and set of extensions in Vulkan. Sometimes they are based on established code patterns that make sense at a specific design layer.

Type support for float16, boolean, int64, int8, etc. has come up across several PRs and issues^[1], so I think it would be useful if we had a central place (e.g. a markdown file, a page on our website, this issue?) that lays out our views on how types are / should be handled at the various layers we interact with.

Some points I'd like to see covered:

• index types vs specific bit depths
• how to represent boolean types efficiently down through codegen to targets with no native support for lower bit depth integers
• how to handle 64 bit types (and the fact that many targets we care about either do not support them, or only support them optionally)
• fixed-point operations (where bit exactness matters), see https://llvm.discourse.group/t/fixed-point-integer-operations/2995
• when to truncate or pad, when to emulate, and when to bit pack (or maybe just some general acknowledgement that there are various ways to map from an input set of types to an output set of types while preserving correctness)

---

^[1] For example: #3102, #3066, #958, #3536, #2574, #5240

[benvanik]

Replacing VMLA will help with this - once we have linalg-on-tensors everywhere a lot of these issues can be cleanly broken into two categories: host-side data types and device-side data types (where device-side data types effectively means "things stored in tensors"). Upstream support in linalg/its target dialects for emulation covers most cases, but that's hard to reason about today as we need to support the non-linalg paths with hacks.

[GMNGeoffrey]

I would love to see this documentation also exist as more helpful error messages. A lot of the time we have things getting way too far with an unsupported type such that the error mode is very confusing

[ScottTodd]

I'll start a page for this.