Stream: git-wasmtime

Topic: wasmtime / PR #2490 x64 lowering fix: i32.popcnt should n...


view this post on Zulip Wasmtime GitHub notifications bot (Dec 08 2020 at 19:56):

cfallin requested abrown and julian-seward1 for a review on PR #2490.

view this post on Zulip Wasmtime GitHub notifications bot (Dec 08 2020 at 19:56):

cfallin requested abrown and julian-seward1 for a review on PR #2490.

view this post on Zulip Wasmtime GitHub notifications bot (Dec 08 2020 at 19:56):

cfallin opened PR #2490 from fix-popcnt-load-width to main:

As a subtle consequence of the recent load-op fusion, popcnt of a
value that came from a load.i32 was compiling into a 64-bit load. This
is a result of the way in which x86 infers the width of loads: it is a
consequence of the instruction containing the memory reference, not the
memory reference itself. So the input_to_reg_mem() helper (convert an
instruction input into a register or memory reference) was providing the
appropriate memory reference for the result of a load.i32, but never
encoded the assumption that it would only be used in a 32-bit
instruction. It turns out that popcnt.i32 uses a 64-bit instruction to
load this RM op, hence widening a 32-bit to 64-bit load (which is
problematic when the offset is (memory_length - 4)).

Separately, popcnt was using the RM operand twice, resulting in two
loads if we merged a load. This isn't a correctness bug in practice
because only a racy sequence (store interleaving between the loads)
would produce incorrect results, but we decided earlier to treat loads
as effectful for now, neither reordering nor duplicating them, to
deliberately reduce complexity.

Because of the second issue, the fix is just to force the operand into a
register always, so any source load will not be merged.

Discovered via fuzzing with oss-fuzz.

<!--

Please ensure that the following steps are all taken care of before submitting
the PR.

Please ensure all communication adheres to the code of conduct.
-->

view this post on Zulip Wasmtime GitHub notifications bot (Dec 08 2020 at 20:18):

bjorn3 submitted PR Review.

view this post on Zulip Wasmtime GitHub notifications bot (Dec 08 2020 at 20:18):

bjorn3 created PR Review Comment:

                // N.B.: explicitly put input in a reg here because the width of the instruction

view this post on Zulip Wasmtime GitHub notifications bot (Dec 08 2020 at 20:24):

cfallin submitted PR Review.

view this post on Zulip Wasmtime GitHub notifications bot (Dec 08 2020 at 20:24):

cfallin created PR Review Comment:

Thanks!

view this post on Zulip Wasmtime GitHub notifications bot (Dec 08 2020 at 20:24):

cfallin updated PR #2490 from fix-popcnt-load-width to main:

As a subtle consequence of the recent load-op fusion, popcnt of a
value that came from a load.i32 was compiling into a 64-bit load. This
is a result of the way in which x86 infers the width of loads: it is a
consequence of the instruction containing the memory reference, not the
memory reference itself. So the input_to_reg_mem() helper (convert an
instruction input into a register or memory reference) was providing the
appropriate memory reference for the result of a load.i32, but never
encoded the assumption that it would only be used in a 32-bit
instruction. It turns out that popcnt.i32 uses a 64-bit instruction to
load this RM op, hence widening a 32-bit to 64-bit load (which is
problematic when the offset is (memory_length - 4)).

Separately, popcnt was using the RM operand twice, resulting in two
loads if we merged a load. This isn't a correctness bug in practice
because only a racy sequence (store interleaving between the loads)
would produce incorrect results, but we decided earlier to treat loads
as effectful for now, neither reordering nor duplicating them, to
deliberately reduce complexity.

Because of the second issue, the fix is just to force the operand into a
register always, so any source load will not be merged.

Discovered via fuzzing with oss-fuzz.

<!--

Please ensure that the following steps are all taken care of before submitting
the PR.

Please ensure all communication adheres to the code of conduct.
-->

view this post on Zulip Wasmtime GitHub notifications bot (Dec 09 2020 at 05:18):

julian-seward1 submitted PR Review.

view this post on Zulip Wasmtime GitHub notifications bot (Dec 09 2020 at 06:28):

cfallin merged PR #2490.


Last updated: Dec 23 2024 at 13:07 UTC