Skip to content

Inconsistent results when using --arith-unsigned-when-equivalent --int-range-optimizations #82158

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
AnonymousBugreporter1 opened this issue Feb 18, 2024 · 1 comment · Fixed by #91737
Assignees
Labels

Comments

@AnonymousBugreporter1
Copy link

I have the following MLIR program:
test.mlir:

module {
  func.func @func1() {
    %c8_i32 = arith.constant 8 : i32
    %c29326_i32 = arith.constant 29326 : i32
    %c2_i32 = arith.constant 2 : i32
    %c1_i32 = arith.constant 1 : i32

    %30 = arith.shrsi %c29326_i32, %c2_i32 : i32 // the result should be 7331, which is 1110010100011 of binary
    %47 = math.ctpop %30 : i32 // the result should be 7
    %57 = arith.shli %47, %c1_i32 : i32 // the result should be 14
    %65 = arith.ceildivsi %57, %c8_i32 : i32 // the result should be 2
    vector.print %65 : i32
    return
  }
}

However, when I ran mlir-opt --arith-expand --arith-unsigned-when-equivalent --int-range-optimizations test.mlir on the program, I got the following result:

module {
  func.func @func1() {
    %c-536870910_i32 = arith.constant -536870910 : i32
    vector.print %c-536870910_i32 : i32
    return
  }
}

And when I ran mlir-opt --arith-expand --int-range-optimizations test.mlir on the program, I got the following result:

 module {
  func.func @func1() {
    %c1_i32 = arith.constant 1 : i32
    vector.print %c1_i32 : i32
    return
  }
}

I've tried to analyze my program manually, and my result is that the value of the constant operation seems to be 2, which is different from either of the above results. I'm not sure if there is any bug in my program or some other problems that caused these results.
My git version is 1a8c613.

@ubfx ubfx self-assigned this Feb 21, 2024
ubfx added a commit to ubfx/llvm-project that referenced this issue May 10, 2024
When an overflow happens during shift left, i.e. the last sign bit or
the most significant data bit gets shifted out, the current approach of
inferring the range of results does not work anymore.

This patch checks for possible overflow and returns the max range in that
case.

Fix llvm#82158
ubfx added a commit that referenced this issue May 13, 2024
When an overflow happens during shift left, i.e. the last sign bit or
the most significant data bit gets shifted out, the current approach of
inferring the range of results does not work anymore.

This patch checks for possible overflow and returns the max range in
that case.

Fix #82158
@llvmbot
Copy link
Member

llvmbot commented May 13, 2024

@llvm/issue-subscribers-mlir

Author: None (wangyongj1a)

I have the following MLIR program: test.mlir: ``` module { func.func @func1() { %c8_i32 = arith.constant 8 : i32 %c29326_i32 = arith.constant 29326 : i32 %c2_i32 = arith.constant 2 : i32 %c1_i32 = arith.constant 1 : i32
%30 = arith.shrsi %c29326_i32, %c2_i32 : i32 // the result should be 7331, which is 1110010100011 of binary
%47 = math.ctpop %30 : i32 // the result should be 7
%57 = arith.shli %47, %c1_i32 : i32 // the result should be 14
%65 = arith.ceildivsi %57, %c8_i32 : i32 // the result should be 2
vector.print %65 : i32
return

}
}

However, when I ran ```mlir-opt --arith-expand --arith-unsigned-when-equivalent --int-range-optimizations test.mlir``` on the program, I got the following result:

module {
func.func @func1() {
%c-536870910_i32 = arith.constant -536870910 : i32
vector.print %c-536870910_i32 : i32
return
}
}

And when I ran ```mlir-opt --arith-expand --int-range-optimizations test.mlir``` on the program, I got the following result:

module {
func.func @func1() {
%c1_i32 = arith.constant 1 : i32
vector.print %c1_i32 : i32
return
}
}

I've tried to analyze my program manually, and my result is that the value of the constant operation seems to be 2, which is different from either of the above results. I'm not sure if there is any bug in my program or some other problems that caused these results.
My git version is 1a8c6130f60fe517fb722ab4309997ce7b638234.

</details>

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants