whitequark edited PR #1789 from x86_32-legalize-loadstore32.i64
to master
:
Fixes #1747.
Doesn't work yet due to https://github.com/bytecodealliance/wasmtime/issues/1747#issuecomment-636098907.
whitequark updated PR #1789 from x86_32-legalize-loadstore32.i64
to master
:
Fixes #1747.
Doesn't work yet due to https://github.com/bytecodealliance/wasmtime/issues/1747#issuecomment-636098907.
whitequark edited PR #1789 from x86_32-legalize-loadstore32.i64
to master
:
Fixes #1747.
whitequark updated PR #1789 from x86_32-legalize-loadstore32.i64
to master
:
Fixes #1747.
bjorn3 submitted PR Review.
bjorn3 submitted PR Review.
bjorn3 created PR Review Comment:
v1 = sload32.i32 v0
same for
uload32
.
whitequark updated PR #1789 from x86_32-legalize-loadstore32.i64
to master
:
Fixes #1747.
whitequark has marked PR #1789 as ready for review.
whitequark created PR Review Comment:
Done. I'm not sure why it worked before the change...
whitequark submitted PR Review.
abrown submitted PR Review.
abrown created PR Review Comment:
In this legalization we are trying to store the lower 32 bits of an
I64
. It makes sense to me that this would be innarrow
.
abrown edited PR Review Comment.
abrown submitted PR Review.
abrown created PR Review Comment:
This seems to use an
I32
pointer (the controlling type) to load the low 32 bits of a register and then sign-extend to 64 bits (from the instruction definition). In 32-bit x86, what is this operation supposed to be doing? If there are no 64-bit registers available for this sign-extension, issextend.I64
going to legalize further to something else? And is that actually what you want? E.g. if bit 31 is 0, should another register be zeroed out; or if bit 31 is 1, should another register be set to all 1s?
abrown submitted PR Review.
abrown created PR Review Comment:
This uses an
I32
pointer (the controlling type) to load the low 32 bits of a register and then just extend (unsigned) to 64 bits. In 32-bit x86, I would think thatuextend.I64
should just zero out another register?
whitequark submitted PR Review.
whitequark created PR Review Comment:
is
sextend.I64
going to legalize further to something else?Yes. In cases that I see (and I get no new legalizer failures with the
*32
instructions)sextend.I64
is then processed byisplit
, and the top half is usually just thrown away. I have no special insight for why Cranelift emitssload32
instructions though.
whitequark submitted PR Review.
whitequark created PR Review Comment:
You're correct that this could be replaced with just
iconst
, I kept it symmetric but there's no reason other than that.
bjorn3 submitted PR Review.
bjorn3 created PR Review Comment:
sload32
instuctions are emitted for a certain WASM instruction.
bjorn3 submitted PR Review.
bjorn3 created PR Review Comment:
I believe that is exactly how
uextend.i64
is legalized on i686.
abrown submitted PR Review.
abrown created PR Review Comment:
Ok, yeah I see it in
code_translator.rs
. I think a summary of our back and forth here would be helpful as a comment on these legalizations. The only other remaining issue is: why can't this be in thewiden
group? @bjorn3, is that clear to you?
abrown submitted PR Review.
abrown created PR Review Comment:
:+1:
bjorn3 submitted PR Review.
bjorn3 created PR Review Comment:
The ctrl typevar is
I32
, which matches the native pointer size on x86_32, so it requires theexpand
group.widen
is only for ctrl typevars that are smaller than the native pointer size.
abrown submitted PR Review.
abrown created PR Review Comment:
Ah, good. Yeah, let's add that nice detail to the comment as well.
alexcrichton edited PR #1789 from x86_32-legalize-loadstore32.i64
to main
:
Fixes #1747.
whitequark updated PR #1789 from x86_32-legalize-loadstore32.i64
to main
:
Fixes #1747.
whitequark closed without merge PR #1789.
Last updated: Dec 23 2024 at 13:07 UTC