Stream: git-wasmtime

Topic: wasmtime / issue #11927 Cranelift: `opt_level=speed` brea...


view this post on Zulip Wasmtime GitHub notifications bot (Oct 23 2025 at 17:01):

emturner opened issue #11927:

When compiling with opt_level=speed, sdiv i64::MIN, i64::MIN returns -1 instead of 1.

The same occurs with opt_level=speed_and_size.

.clif Test Case

test interpret
test run
set opt_level=speed
target x86_64

function %sdiv_by_const_neg_i64min_i64(i64) -> i64 {
block0(v0: i64):
    v1 = iconst.i64 -9223372036854775808
    v2 = sdiv v0, v1
    return v2
}

; run: %sdiv_by_const_neg_i64min_i64(-9223372036854775808) == 1

Steps to Reproduce

Expected Results

The test should pass. i64::MIN / i64::MIN == 1.

Actual Results

We get an incorrect result: i64::MIN / i64::MIN == -1

Versions and Environment

Cranelift version or commit: f678260bb3b2fa07ae10737f581b2d395d3349da is the first commit that causes the issue.

All cranelift versions from then on (1.22.0 -> current @ 1.25.1) are affected.

Operating system: Guix Linux @ 6.16.7, Ubuntu 24.04.3 LTS. Mac M2 possibly also affected (will confirm).

Architecture: AMD64, x86_64

Extra Info

As far as I can tell, the algorithm for the 'const denominator division' is correct. Indeed the proptests are correct. There appears to be some issue in how the constants are all inligned from the smulhi and the various shifts in the fast algorithm. All other values appear to work correctly.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 23 2025 at 17:01):

emturner added the bug label to Issue #11927.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 23 2025 at 17:01):

emturner added the cranelift label to Issue #11927.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 23 2025 at 17:43):

emturner edited issue #11927:

When compiling with opt_level=speed, sdiv i64::MIN, i64::MIN returns -1 instead of 1.

The same occurs with opt_level=speed_and_size.

.clif Test Case

test interpret
test run
set opt_level=speed
target x86_64

function %sdiv_by_const_neg_i64min_i64(i64) -> i64 {
block0(v0: i64):
    v1 = iconst.i64 -9223372036854775808
    v2 = sdiv v0, v1
    return v2
}

; run: %sdiv_by_const_neg_i64min_i64(-9223372036854775808) == 1

Steps to Reproduce

Expected Results

The test should pass. i64::MIN / i64::MIN == 1.

Actual Results

We get an incorrect result: i64::MIN / i64::MIN == -1

Versions and Environment

Cranelift version or commit: f678260bb3b2fa07ae10737f581b2d395d3349da is the first commit that causes the issue.

All cranelift versions from then on (1.22.0 -> current @ 1.25.1) are affected.

Operating system: Guix Linux @ 6.16.7, Ubuntu 24.04.3 LTS. Mac M2 possibly also affected (will confirm).

Architecture: AMD64, x86_64

Extra Info

As far as I can tell, the algorithm for the 'const denominator division' is correct. Indeed the proptests cover this case.

My best guess is that there could be some issue in how the constants are all inlined from the smulhi and the various other shifts in the fast algorithm. All other values appear to work correctly.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 24 2025 at 09:18):

emturner commented on issue #11927:

This also happens with i32 signed division.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 24 2025 at 11:42):

emturner edited issue #11927:

When compiling with opt_level=speed, sdiv i64::MIN, i64::MIN returns -1 instead of 1.

The same occurs with opt_level=speed_and_size.

.clif Test Case

test interpret
test run
set opt_level=speed
target x86_64

function %sdiv_by_const_neg_i64min_i64(i64) -> i64 {
block0(v0: i64):
    v1 = iconst.i64 -9223372036854775808
    v2 = sdiv v0, v1
    return v2
}

; run: %sdiv_by_const_neg_i64min_i64(-9223372036854775808) == 1

Steps to Reproduce

Expected Results

The test should pass. i64::MIN / i64::MIN == 1.

Actual Results

We get an incorrect result: i64::MIN / i64::MIN == -1

Versions and Environment

Cranelift version or commit: f678260bb3b2fa07ae10737f581b2d395d3349da is the first commit that causes the issue.

All cranelift versions from then on (1.22.0 -> current @ 1.25.1) are affected.

Operating system: Guix Linux @ 6.16.7, Ubuntu 24.04.3 LTS, Mac M2.

Architecture: AMD64, x86_64

Extra Info

As far as I can tell, the algorithm for the 'const denominator division' is correct. Indeed the proptests cover this case.

My best guess is that there could be some issue in how the constants are all inlined from the smulhi and the various other shifts in the fast algorithm. All other values appear to work correctly.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 24 2025 at 11:42):

emturner edited issue #11927:

When compiling with opt_level=speed, sdiv i64::MIN, i64::MIN returns -1 instead of 1.

The same occurs with opt_level=speed_and_size.

.clif Test Case

test interpret
test run
set opt_level=speed
target x86_64

function %sdiv_by_const_neg_i64min_i64(i64) -> i64 {
block0(v0: i64):
    v1 = iconst.i64 -9223372036854775808
    v2 = sdiv v0, v1
    return v2
}

; run: %sdiv_by_const_neg_i64min_i64(-9223372036854775808) == 1

Steps to Reproduce

Expected Results

The test should pass. i64::MIN / i64::MIN == 1.

Actual Results

We get an incorrect result: i64::MIN / i64::MIN == -1

Versions and Environment

Cranelift version or commit: f678260bb3b2fa07ae10737f581b2d395d3349da is the first commit that causes the issue.

All cranelift versions from then on (1.22.0 -> current @ 1.25.1) are affected.

Operating system: Guix Linux @ 6.16.7, Ubuntu 24.04.3 LTS, MacOS.

Architecture: AMD64, x86_64, Mac M2.

Extra Info

As far as I can tell, the algorithm for the 'const denominator division' is correct. Indeed the proptests cover this case.

My best guess is that there could be some issue in how the constants are all inlined from the smulhi and the various other shifts in the fast algorithm. All other values appear to work correctly.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 24 2025 at 11:55):

emturner edited issue #11927:

When compiling with opt_level=speed, sdiv i64::MIN, i64::MIN returns -1 instead of 1.

The same occurs with opt_level=speed_and_size.

.clif Test Case

test interpret
test run
set opt_level=speed
target x86_64

function %sdiv_by_const_neg_i64min_i64(i64) -> i64 {
block0(v0: i64):
    v1 = iconst.i64 -9223372036854775808
    v2 = sdiv v0, v1
    return v2
}

; run: %sdiv_by_const_neg_i64min_i64(-9223372036854775808) == 1

Steps to Reproduce

Expected Results

The test should pass. i64::MIN / i64::MIN == 1.

Actual Results

We get an incorrect result: i64::MIN / i64::MIN == -1

Versions and Environment

Cranelift version or commit: f678260bb3b2fa07ae10737f581b2d395d3349da is the first commit that causes the issue.

All cranelift versions from then on (1.22.0 -> current @ 1.25.1) are affected.

Operating system: Guix Linux @ 6.16.7, Ubuntu 24.04.3 LTS, MacOS.

Architecture: AMD64, x86_64, Mac M2.

Extra Info

As far as I can tell, the algorithm for the 'const denominator division' is correct. Indeed the proptests cover this case.

~My best guess is that there could be some issue in how the constants are all inlined from the smulhi and the various other shifts in the fast algorithm. All other values appear to work correctly.~

EDIT: the incorrect rule fires in the case of sdiv where d == ty::MIN. Namely, the rule for _positive_ power of two fires instead of _negative_ power of two.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 29 2025 at 15:05):

cfallin closed issue #11927:

When compiling with opt_level=speed, sdiv i64::MIN, i64::MIN returns -1 instead of 1.

The same occurs with opt_level=speed_and_size.

.clif Test Case

test interpret
test run
set opt_level=speed
target x86_64

function %sdiv_by_const_neg_i64min_i64(i64) -> i64 {
block0(v0: i64):
    v1 = iconst.i64 -9223372036854775808
    v2 = sdiv v0, v1
    return v2
}

; run: %sdiv_by_const_neg_i64min_i64(-9223372036854775808) == 1

Steps to Reproduce

Expected Results

The test should pass. i64::MIN / i64::MIN == 1.

Actual Results

We get an incorrect result: i64::MIN / i64::MIN == -1

Versions and Environment

Cranelift version or commit: f678260bb3b2fa07ae10737f581b2d395d3349da is the first commit that causes the issue.

All cranelift versions from then on (1.22.0 -> current @ 1.25.1) are affected.

Operating system: Guix Linux @ 6.16.7, Ubuntu 24.04.3 LTS, MacOS.

Architecture: AMD64, x86_64, Mac M2.

Extra Info

As far as I can tell, the algorithm for the 'const denominator division' is correct. Indeed the proptests cover this case.

~My best guess is that there could be some issue in how the constants are all inlined from the smulhi and the various other shifts in the fast algorithm. All other values appear to work correctly.~

EDIT: the incorrect rule fires in the case of sdiv where d == ty::MIN. Namely, the rule for _positive_ power of two fires instead of _negative_ power of two.


Last updated: Dec 06 2025 at 06:05 UTC