Skip to content
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.

Sign up for GitHub

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

Jump to bottom

[mlir] Inconsistent results for arith.ceildivsi #115293

Open
wangyongj1a opened this issue Nov 7, 2024 · 3 comments · May be fixed by #116284
Open

[mlir] Inconsistent results for arith.ceildivsi #115293

wangyongj1a opened this issue Nov 7, 2024 · 3 comments · May be fixed by #116284
Labels
mlir:arith

Comments

@wangyongj1a
Copy link

I have the following MLIR program:
test.mlir:

module {
  func.func @func1() -> f32 {
    %c1189465982_i64 = arith.constant 1189465982 : i64
    %c-9223372036854775808_i64 = arith.constant -9223372036854775808 : i64
    %156 = arith.ceildivsi %c-9223372036854775808_i64, %c1189465982_i64 : i64
    vector.print %156 : i64
    %0 = arith.sitofp %156 : i64 to f32
    return %0 : f32
  }
}

When I ran /data/tmp/v1107/llvm-project/build/bin/mlir-opt --int-range-optimizations --arith-expand --convert-arith-to-llvm --convert-vector-to-llvm --convert-func-to-llvm --reconcile-unrealized-casts test.mlir | /data/tmp/v1107/llvm-project/build/bin/mlir-cpu-runner -e func1 --shared-libs=/data/tmp/v1107/llvm-project/build/lib/libmlir_runner_utils.so,/data/tmp/v1107/llvm-project/build/lib/libmlir_c_runner_utils.so on the program, I got the result of:

-7754212542
-7.754212e+09

However, when I ran /data/tmp/v1107/llvm-project/build/bin/mlir-opt --arith-expand --convert-arith-to-llvm --convert-vector-to-llvm --convert-func-to-llvm --reconcile-unrealized-casts test.mlir | /data/tmp/v1107/llvm-project/build/bin/mlir-cpu-runner -e func1 --shared-libs=/data/tmp/v1107/llvm-project/build/lib/libmlir_runner_utils.so,/data/tmp/v1107/llvm-project/build/lib/libmlir_c_runner_utils.so on the program, I got the result of:

7754212542
7.754212e+09

The above two results seem to be inconsistent. I'm not sure if there is any bug in my program or if the wrong usage of the above passes caused these results.

My git version is 1469d82.
@github-actions github-actions bot added the mlir label Nov 7, 2024
@wangyongj1a
Copy link
Author

I tried to reproduce this issue on history commit versions, and I found these inconsistence results can be reproduced on commit 4722911, and cannot be reproduced on the previous commit 3e39328. Hi @krzysz00, sorry to disturb but I was wondering if you would mind taking a look at this problem?

@krzysz00
Copy link
Contributor

@Mogball @River707 Having stared at this (and noticed that --arith-expand-ops --canonicalize on the input gives a simpler reproducer), I think the expansion of CeilDivSI is incorrect - a negative number divided by a positive number, rounded up, should still be negative.

@krzysz00
Copy link
Contributor

On further investigation, the issue is that --arith-expand isn't lowering to logic that handles a ceildiv b where a = INT_MIN , which overflows.

From where I'm standing:

  1. In arbitrary precision, the negative result is correct
  2. The positive result isn't unreasonable for some of the usual ceil_div functions you can find out there

I suspect that, since it looks like this is defined behavior, I need to go add some cases to integer range analysis

krzysz00 added a commit to krzysz00/llvm-project that referenced this issue Nov 14, 2024
@krzysz00
[mlir][IntRangeInference] Handle ceildivsi(INT_MIN, x > 1) as expected
0ec5b1c 
Fixes llvm#115293

While the definition of ceildivsi is integer division, rounding up,
most implementations will use `-(-a / b)` for dividing `a ceildiv b`
with `a` negative and `b` positive.

Mathematically, and for most integers, these two definitions are
equivalent. However, with `a == INT_MIN`, the initial negation is a
noop, which means that, while divinding and rounding up would give a
negative result, `-((- INT_MIN) / b)` is `-(INT_MIN / b)`, which is
positive.

This commit adds a special case to ceilDivSI inference to handle this
case and bring it in line with the operational instead of the
mathematical semantics of ceiling division.
@krzysz00 krzysz00 linked a pull request Nov 14, 2024 that will close this issue
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
mlir:arith
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

[mlir][IntRangeInference] Handle ceildivsi(INT_MIN, x > 1) as expected krzysz00/llvm-project
3 participants
@krzysz00 @EugeneZelenko @wangyongj1a