Overflows during folding of basic `arith` ops

MLIR
6

I think the confusion might be here that arith.adids documentation is underspecified in this case. See [RFC] Define precise arith semantics e.g.
Is it possible that you are expecting some particular semantics for signed integer overflow?

The overflow semantics of addi are currently implemented as wraparound semantics (regardless of which sign you interpret it as). This means our desired result for your example in particular is -126 if interpreted as a signed number due to signed integer wraparound.
-126 happens to be the exact same bit pattern as 130 when using twos complement (10000010) making them equivalent. MLIR therefore treats them as the exact same integer attribute.
E.g. CSE will turn:

func.func @test() -> (i8, i8) {
    %0 = arith.constant 130 : i8
    %1 = arith.constant -126 : i8
    return %0, %1 : i8, i8
}

into just

func.func @test() -> (i8, i8) {
  %c-126_i8 = arith.constant -126 : i8
  return %c-126_i8, %c-126_i8 : i8, i8
}

(Compiler Explorer)

So is as you said it is “handling both signed and unsigned integers” (the result is 130 if interpreted as unsigned, -126 due to signed integer wraparound if interpreted as signed integers).

2 Likes