Stream: git-wasmtime

Topic: wasmtime / Issue #2622 Expand x64 OperandSize to support ...

Wasmtime GitHub notifications bot (Jan 29 2021 at 09:34):

kaseyc commented on Issue #2622:

Hi @cfallin,

This is still WIP but I wanted to get a sign-off on the general direction before I actually start rewriting all the other instructions to use OperandSize.

This won't handle Nop instructions, but they're kind of a special case and maybe don't need to use OperandSize.

Wasmtime GitHub notifications bot (Jan 29 2021 at 17:03):

cfallin commented on Issue #2622:

@kaseyc yes, this is the right general direction; thanks for tackling this!

This won't handle Nop instructions, but they're kind of a special case and maybe don't need to use OperandSize.

Yes, NOPs don't really have operands, per-se, so I don't think it would make sense to try to use this enum for their size specification (i.e. in that case it is instruction size, not operand size).

Wasmtime GitHub notifications bot (Jan 30 2021 at 04:44):

iximeow commented on Issue #2622:

almost-useless pedantry: x86 nops' memory operands have something of a history of turning into prefetches with the memory operand interpreted as encoded. i would pretty strongly disrecommend treating OperandSize differently in their case unless there's a good representation win for it. 0f1f /0 nops will always be nop, but the adjacent hinted nops may grow future semantics.

and my closing argument: Intel's xed decoder does report 66 0f1f 44 0000 f.ex as nop word ptr [rax+rax*1], ax (and a 67 prefix makes the address decode with eax instead!) - for the wide nops (and prefetches) the memory operand is decoded as the bytes would mean for any other memory-operand instruction

Wasmtime GitHub notifications bot (Jan 30 2021 at 04:45):

iximeow edited a comment on Issue #2622:

almost-useless pedantry: x86 nops' memory operands have something of a history of turning into prefetches with the memory operand interpreted as encoded. i would pretty strongly disrecommend treating OperandSize differently in their case unless there's a good representation win for it. 0f1f /0 nops will always be nop, but the adjacent hinted nops may grow future semantics.

and my closing argument: Intel's xed decoder does report 66 0f1f 44 0000 f.ex as nop word ptr [rax+rax*1], ax (and a 67 prefix makes the address decode with eax instead!) - for the wide nops (and prefetches) the memory operand is decoded as the bytes would mean for any other memory-operand instruction

edit: but to be clear i totally support _ignoring_ OperandSize in the case of emitting nops :D

Wasmtime GitHub notifications bot (Feb 01 2021 at 01:50):

kaseyc commented on Issue #2622:

I've updated most of the instructions to use OperandSize now.

There are a couple that get from ir::Type such as LockCmpXxchg and AtomicRmwSeq, but those are trickier to modify.

For the clarity/readability I have put the u8->OperandSize and bool->OperandSize refactors into separate commits.

Last updated: Dec 23 2024 at 12:05 UTC