*Continuing the discussion from D76136 [1] and D76137 [2]*

D72533 [3] introduced signed / unsigned integer types to MLIR with the goal to provide common infrastructure for dialects that wish to model represent signedness explicitly.

D76136 [1] and D76137 [2] started adding support for such types for certain ops of std, based on the misinterpretation of D72533 [3] as the introduction of signed / unsigned integer types in general. The MLIR Rationale explicitly states that integer types in std are signless [4].

However, for projects that wish to model signedness and that rely heavily on std, such as the Teckyl Tensor Expression Frontend [5], from which the patches originate, this means that they either need to re-implement a certain number of operations from std or they need to convert operands to signless integers and back. The former is quite redundant, while the latter probably requires some work on integer types, as there does not seem to be any infrastructure for the conversion between signless and signed / unsigned integers.

I understand the motivations to keep signless integers in std wherever possible, but I would like to open the discussion on the above-mentioned issues. Any hints on how to work around this are highly appreciated.

Thanks!

**References**

[1] https://reviews.llvm.org/D76136

[2] https://reviews.llvm.org/D76137

[3] https://reviews.llvm.org/D72533

[4] https://mlir.llvm.org/docs/Rationale/#integer-signedness-semantics

[5] https://github.com/andidr/teckyl/