[MLIR][Arith] Invalid SelectOp folding

[7FM]

In CIRCT, we have a dialect named hwarith to represent arithmetics that persist signedness information and prevent unintentional under- and overflows.
Using this dialect in combination with arith.select revealed an issue. Take the following example code:

func.func @test(%sel : i1) -> ui1 {
  %trueVal = hwarith.constant 1 : ui1
  %falseVal = hwarith.constant 0 : ui1
  %res = arith.select %sel, %trueVal, %falseVal : ui1
  func.return %res : ui1
}

The SelectOp's folder tries to replace the SelectOp directly with %sel. However, %sel is of type i1 whereas the true- and falseVal values are of type ui1. Consequently, the following crash is caused: error: 'arith.select' op folder produced a value of incorrect type: 'i1', expected: 'ui1'.

The corresponding pattern matching code has a bit-width check for the return type but lacks a signedness check and thus implicitly assumes that the return type is signless (i1):

llvm-project/mlir/lib/Dialect/Arith/IR/ArithOps.cpp

Lines 2317 to 2319 in 612f8ec

	if (getType().isInteger(1) && matchPattern(adaptor.getTrueValue(), m_One()) &&
	matchPattern(adaptor.getFalseValue(), m_Zero()))
	return condition;

[llvmbot]

@llvm/issue-subscribers-bug

Author: None (7FM)

In CIRCT, we have a dialect named `hwarith` to represent arithmetics that persist signedness information and prevent unintentional under- and overflows. Using this dialect in combination with `arith.select` revealed an issue. Take the following example code: ``` func.func @test(%sel : i1) -> ui1 { %trueVal = hwarith.constant 1 : ui1 %falseVal = hwarith.constant 0 : ui1 %res = arith.select %sel, %trueVal, %falseVal : ui1 func.return %res : ui1 } ``` The SelectOp's folder tries to replace the SelectOp directly with `%sel`. However, `%sel` is of type `i1` whereas the true- and falseVal values are of type `ui1`. Consequently, the following crash is caused: `error: 'arith.select' op folder produced a value of incorrect type: 'i1', expected: 'ui1'`.

The corresponding pattern matching code has a bit-width check for the return type but lacks a signedness check and thus implicitly assumes that the return type is signless (i1):

llvm-project/mlir/lib/Dialect/Arith/IR/ArithOps.cpp

Lines 2317 to 2319 in 612f8ec

	if (getType().isInteger(1) && matchPattern(adaptor.getTrueValue(), m_One()) &&
	matchPattern(adaptor.getFalseValue(), m_Zero()))
	return condition;