wasmtime / issue #10719 Cranelift: confusing compiler out... · git-wasmtime

Stream: git-wasmtime

Topic: wasmtime / issue #10719 Cranelift: confusing compiler out...

Wasmtime GitHub notifications bot (May 02 2025 at 23:15):

abrown added the bug label to Issue #10719.

Wasmtime GitHub notifications bot (May 02 2025 at 23:15):

abrown added the cranelift label to Issue #10719.

Wasmtime GitHub notifications bot (May 02 2025 at 23:15):

See the following existing compilation test:

https://github.com/bytecodealliance/wasmtime/blob/e0431281326eb13b45af0d6dd7829304e18581d4/cranelift/filetests/filetests/isa/x64/simd-lane-access-compile.clif#L134-L137

A constant from the post-function pool is being loaded into %xmm1, but the instruction that would use it paddusb, then re-loads it as it writes into %xmm1. Now, the movdqu seems correct in one sense: memory addresses to packed instructions must be 128-bit aligned so, when converting an XmmMemAligned to an XmmMem, Cranelift inserts an unaligned load. But the direct use by paddusb might also be correct: we may be aligning the start of the constant pool and so this may be just fine.

Either way, something is not quite right, though:

if the constant pool is _not_ aligned or this can't be communicated to the instruction, paddusb should not be using the address directly

if the constant pool _is_ aligned and communicated properly, then the movdqu is redundant and should be removed

Which is it? I'm leaning towards the latter because of sequences like the following:

https://github.com/bytecodealliance/wasmtime/blob/e0431281326eb13b45af0d6dd7829304e18581d4/cranelift/filetests/filetests/isa/x64/simd-pairwise-add.clif#L154-L156

Those instructions have no trouble accessing the pool by aligned address... or are they incorrect?

Wasmtime GitHub notifications bot (May 02 2025 at 23:25):

cfallin commented on issue #10719:

The constant pool does align 128-bit constants: here and then used here.

I'm not sure I understand the "movdqu is redundant" point though: there are two constants here, and two movdqus; the first movdqu loads the same constant as the paddusb does, but into xmm0, not xmm1; the second movdqu loads a different constant. It looks like it's true that the paddusb doesn't reuse the value in xmm0 -- is that the part you mean?

Wasmtime GitHub notifications bot (May 02 2025 at 23:37):

abrown commented on issue #10719:

I should have narrowed down that code snippet to:
movdqu 0x1c(%rip), %xmm1
paddusb 0x24(%rip), %xmm1
What I see is both of these instructions loading the same constant, only the offsets are different because the instructions each live at different %rip locations. Does that make more sense?

Wasmtime GitHub notifications bot (May 02 2025 at 23:56):

cfallin commented on issue #10719:

Ah! OK, so it's a deduplication issue? I don't think we dedup 128-bit constants right now; I don't recall why not, off the top of my head. If we did that, then in theory it should be possible to GVN the two arguments...

Last updated: Dec 06 2025 at 06:05 UTC