Currently, only signless integers are allowed as constants. This patch additionally allows for explicitly signed and explicitly unsigned integer constants.
Thanks for the patch! StandardOps is designed to use only signless integers, any deviation will require an RFC and justification as to why the change is desired. See https://mlir.llvm.org/docs/Rationale/#integer-signedness-semantics
It seems that I have misinterpreted https://reviews.llvm.org/D72533 as the introduction of explicitly signed / unsigned types to MLIR in general, including std. Thanks for your clarification!
The patch originates from work on a frontend for Tensor Expressions that includes unsigned types in the source language and that generates operations from std and linalg. The translation is implemenyed recursively with functions simply returning mlir::Values. D72533 seemed like a comfortable way to keep this scheme and to avoid modeling the sign externally. However, without support for explicitly signed data types for the operations from std, this means that either the operands need to be converted to signless integers or the operations need to be re-implemented outside of std with support for explicitly signed / unsigned operands. I am not aware of any way to convert the operands and re-implementation of the operations seems quite redundant.
I understand your motivations to keep signless integers in std wherever possible. Any hint on how to work around the above-mentioned issues is highly appreciated. Thanks!
Thanks for pointing this out. This is coherent with my understanding. I'll add test cases for signed integers should the decision to support only signless integers in std be revised.
I'd love to discuss more. To make it easier, could you post about what you are doing on https://llvm.discourse.group/c/llvm-project/mlir/?
Done: https://llvm.discourse.group/t/explicitly-signed-unsigned-integers-in-std/731. Thanks for the suggestion!