Issue 131529
Summary [mlir][vector] Narrow-type-emulation - emulated type constraints
Labels mlir
Assignees
Reporter banach-space
    Hi folks,

I wanted to check whether we could constrain the emulated types in [the narrow type emulation](https://github.com/llvm/llvm-project/blob/main/mlir/lib/Dialect/Vector/Transforms/VectorEmulateNarrowType.cpp). I would like to propose that:
* _The emulated type is always required to be **a sub-byte type**._

Right now, broadly speaking, we have two types of patterns:
1. Patterns that assume that **the emulated type** is indeed **a sub-byte type**, e.g. `i2` is emulated using `i8`.
2. Patterns that make **weaker assumptions about the emulated type** (so that e.g. `i8` can be emulated using `i32` ).

The patterns that fall into the first category are here: https://github.com/llvm/llvm-project/blob/d928a671b84afb9c2ad64353694537a198f04651/mlir/lib/Dialect/Vector/Transforms/VectorEmulateNarrowType.cpp#L2127-L2138

[ConvertVectorLoad](https://github.com/llvm/llvm-project/blob/d928a671b84afb9c2ad64353694537a198f04651/mlir/lib/Dialect/Vector/Transforms/VectorEmulateNarrowType.cpp#L826-L925) is one pattern that falls into the second category.

This "dual" state with mixed level of support between patterns is problematic:
*  This lack of inconsistency is not really documented and the desired end-state is not clear.
* Without consistency, it's much trickier to create common code paths.
* When new patterns are added, how do we decide what level of support to add and test?

Now, I don't want to artificially constrain "narrow-type-emulation", so please let me know if you do require emulating `i8` using e.g. `i32`. The targets that I care about all support `i8` natively, so this wouldn't be a problem for me. However, we need to make sure that this works for everyone. I would ask though that folks take into account the maintenance cost of this. 
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

Reply via email to