wasmtime / PR #14253 Limit alias regions in Wasm-to-CLIF ... · git-wasmtime

Stream: git-wasmtime

Topic: wasmtime / PR #14253 Limit alias regions in Wasm-to-CLIF ...

Wasmtime GitHub notifications bot (Sep 01 2026 at 00:29):

fitzgen opened PR #14253 from fitzgen:limit-number-of-alias-regions to bytecodealliance:main:

Instead of bitpacking the AliasRegionKey into a u32, hash it and then xor-fold the hash down to one byte.

Fixes https://github.com/bytecodealliance/wasmtime/issues/14221

Depends on #14230

Wasmtime GitHub notifications bot (Sep 01 2026 at 00:29):

fitzgen requested cfallin for a review on PR #14253.

Wasmtime GitHub notifications bot (Sep 01 2026 at 00:29):

fitzgen requested wasmtime-compiler-reviewers for a review on PR #14253.

Wasmtime GitHub notifications bot (Sep 01 2026 at 00:29):

fitzgen requested wasmtime-core-reviewers for a review on PR #14253.

Wasmtime GitHub notifications bot (Sep 01 2026 at 03:47):

github-actions[bot] added the label cranelift on PR #14253.

Wasmtime GitHub notifications bot (Sep 03 2026 at 01:09):

gfx commented on PR #14253:

This fixes the problem I reported in #14210.

I used the generator script from that issue and ran wasmtime compile -o /dev/null. Release build, best of 3, macOS / aarch64 only.

N base ffb04089ea this PR

250 0.14 s 0.08 s

500 0.97 s 0.19 s

1000 6.86 s 0.40 s

2000 51.48 s 0.87 s

4000 -- 1.79 s

8000 -- 4.15 s

Time roughly doubles when N doubles, out to N=8000. The blowup is gone and my
module builds again. Thank you.

FYI, the RPO worklist from #14211 is still 3-5x faster on top of this PR
(0.16 s at N=2000, 1.39 s at N=8000), but the gap narrows as N grows, so it is
only a constant factor now. However, I am closing #14211. It conflicts, and this PR fixes what I actually
hit.

One request: if this misses the 49.0.0 branch on the 5th, could it be
backported to release-48.0.0? The slowdown is a serious regression in 48.0.0, and
48.0.x is the current release. I know patch releases are meant for
security and correctness fixes and that backports are volunteer work, so this
is only a request.

N	base `ffb04089ea`	this PR
250	0.14 s	0.08 s
500	0.97 s	0.19 s
1000	6.86 s	0.40 s
2000	51.48 s	0.87 s
4000	--	1.79 s
8000	--	4.15 s

Wasmtime GitHub notifications bot (Sep 03 2026 at 14:58):

:memo: cfallin submitted PR review:

Review on the last commit only (the lattice commit still has work in progress as I understand it from our discussion yesterday, re: scoped hashmap and such).

My main concern with the machinery here is the description-string complexity. Seeing the "reverse map" that keeps original identities around, and especially the string-joining machinery, inside Cranelift itself, both (i) raises serious efficiency concerns for me (we may be at a net speedup by preventing alias-analysis state blowup, but we are still introducing a lot of string munging to produce strings that most compilations will never need), and (ii) seems more complex than it needs to be.

I wonder if we could simply drop the descriptions, and instead emit log::trace lines for mapping of alias-region keys to Cranelift region numbers, and let that suffice for debugging? It seems that all the same information would be there, but we wouldn't be eagerly computing then throwing it away on every compilation...

Wasmtime GitHub notifications bot (Sep 03 2026 at 14:58):

:speech_balloon: cfallin created PR review comment:

This string-joining, and the hashmap-of-hashsets, seem like a lot of machinery to put into the compilation pipeline for a "nice to have" (descriptions that include all original region identities). I wonder if there's a way to avoid it?

Wasmtime GitHub notifications bot (Sep 03 2026 at 14:58):

:speech_balloon: cfallin created PR review comment:

Even with the note about deterministic behavior here, I'm still fairly wary about putting something in the stdlib in the "determinism critical path" -- this way a change in e.g. Rust compiler release used to build Cranelift could shift our outputs and introduce or hide a bug, making bug report triage, fuzzer triage, and general support much more potentially difficult.

Could we instead write a simple hash function by hand (with shifts and XORs and such, the way we used to in the olden times...)?

Wasmtime GitHub notifications bot (Sep 03 2026 at 22:51):

fitzgen updated PR #14253.

Wasmtime GitHub notifications bot (Sep 04 2026 at 10:58):

gfx edited a comment on PR #14253:

This fixes the problem I reported in #14210.

I used the generator script from that issue and ran wasmtime compile -o /dev/null. Release build, best of 3, macOS / aarch64 only.

N base ffb04089ea this PR

250 0.14 s 0.08 s

500 0.97 s 0.19 s

1000 6.86 s 0.40 s

2000 51.48 s 0.87 s

4000 -- 1.79 s

8000 -- 4.15 s

Time roughly doubles when N doubles, out to N=8000. The blowup is gone and my
module builds again. Thank you.

FYI, the RPO worklist from #14211 is still 3-5x faster on top of this PR
(0.16 s at N=2000, 1.39 s at N=8000), but the gap narrows as N grows, so it is
only a constant factor now. However, I am closing #14211. It conflicts, and this PR fixes what I actually
hit.

One request: if this misses the 49.0.0 branch on the 5th, could it be
backported to release-48.0.0? The slowdown is a serious regression in 48.0.0, and
48.0.x is the current release. I know patch releases are meant for
security and correctness fixes and that backports are volunteer work, so this
is only a request.

N	base `ffb04089ea`	this PR
250	0.14 s	0.08 s
500	0.97 s	0.19 s
1000	6.86 s	0.40 s
2000	51.48 s	0.87 s
4000	--	1.79 s
8000	--	4.15 s

Wasmtime GitHub notifications bot (Sep 04 2026 at 10:58):

gfx edited a comment on PR #14253:

This fixes the problem I reported in #14210.

I used the generator script from that issue and ran wasmtime compile -o /dev/null. Release build, best of 3, macOS / aarch64 only.

N base ffb04089ea this PR

250 0.14 s 0.08 s

500 0.97 s 0.19 s

1000 6.86 s 0.40 s

2000 51.48 s 0.87 s

4000 -- 1.79 s

8000 -- 4.15 s

Time roughly doubles when N doubles, out to N=8000. The blowup is gone and my
module builds again. Thank you.

FYI, the RPO worklist from #14211 is still 3-5x faster on top of this PR
(0.16 s at N=2000, 1.39 s at N=8000), but the gap narrows as N grows, so it is
only a constant factor now. However, I am closing #14211. It conflicts, and this PR fixes what I actually
hit.

One request: if this misses the 49.0.0 branch on the 5th, could it be
backported to release-48.0.0? The slowdown is a serious regression in 48.0.0, and
48.0.x is the current release. I know patch releases are meant for
security and correctness fixes and that backports are volunteer work, so this
is only a request.