Summary:
One for register based, much like the existing definitions,
and one for stack based (suffix _S).
This allows us to use registers in most of LLVM (which works better),
and stack based in MC (which results in a simpler and more readable
assembler / disassembler).
Tried to keep this change as small as possible while passing tests,
follow-up commit will:
- Add reg->stack conversion in MI.
- Fix asm/disasm in MC to be stack based.
- Fix emitter to be stack based.
tests passing:
llvm-lit -v `find test -name WebAssembly`
test/CodeGen/WebAssembly
test/MC/WebAssembly
test/MC/Disassembler/WebAssembly
test/DebugInfo/WebAssembly
test/CodeGen/MIR/WebAssembly
test/tools/llvm-objdump/WebAssembly
Reviewers: dschuff, sbc100, jgravelle-google, sunfish
Subscribers: aheejin, JDevlieghere, llvm-commits
Differential Revision: https://reviews.llvm.org/D48183
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@334985 91177308-0d34-0410-b5e6-96231b3b80d8
These encodings correspond to the cases in the normal encoding scheme where there is no index and our modrm reading code initially decodes it as such. The VSIB handling code tried to compensate for this, but failed to add the base needed to make later code do the right thing.
Fixes PR37712.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@334121 91177308-0d34-0410-b5e6-96231b3b80d8
A 5-bit value can occur when EVEX.X is 0 due to it being used to extend modrm.rm to encode XMM16-31. But if modrm.rm instead encodes a GPR, the Intel documentation says EVEX.X should be ignored so just mask it to 4 bits once we know its a GPR.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@333725 91177308-0d34-0410-b5e6-96231b3b80d8
EVEX.X is used to extended modrm.rm when the instruction encodes a XMM/YMM/ZMM register. But we aren't properly ignoring it when it encodes a GPR and we end up printing whatever registers exist in X86 register enum after the GPRs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@333724 91177308-0d34-0410-b5e6-96231b3b80d8
This was an accidental side effect of EVEX.X being used to encode XMM16-XMM31 using modrm.rm with modrm.mod==0x3.
I think there are still more bugs related to this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@333722 91177308-0d34-0410-b5e6-96231b3b80d8
As part of this effort, duplicate and correct the predicates of some
aliases. Also disable code generation of some short form instructions
for FastISel, as it would otherwise reject them.
Reviewers: atanasyan, abeserminji, smaksimovic
Differential Revision: https://reviews.llvm.org/D47075
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@333530 91177308-0d34-0410-b5e6-96231b3b80d8
This implements a new table-gen emitter to create tables for
a wasm disassembler, and a dissassembler to use them.
Comes with 2 tests, that tests a few instructions manually. Is also able to
disassemble large .wasm files with objdump reasonably.
Not working so well, to be addressed in followups:
- objdump appears to be passing an incorrect starting point.
- since the disassembler works an instruction at a time, and it is
disassembling stack instruction, it has no idea of pseudo register assignments.
These registers are required for the instruction printing code that follows.
For now, all such registers appear in the output as $0.
Patch by Wouter van Oortmerssen
Differential Revision: https://reviews.llvm.org/D45848
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@332052 91177308-0d34-0410-b5e6-96231b3b80d8
Previously for instructions like fxsave we would print "opaque ptr" as part of the memory operand. Now we print nothing.
We also no longer accept "opaque ptr" in the parser. We still accept any size to be specified for these instructions, but we may want to consider only parsing when no explicit size is specified. This what gas does.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@331243 91177308-0d34-0410-b5e6-96231b3b80d8
This allows the instruction selection to follow mode in Intel syntax. And allows a suffix to be used to change size.
This matches gas behavior from what I could tell.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@331138 91177308-0d34-0410-b5e6-96231b3b80d8
This encoding is recognized by the CPU, but the behavior is undefined. This makes the disassembler handle it correctly so we don't print bswapl with a 16-bit register.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@330682 91177308-0d34-0410-b5e6-96231b3b80d8
This demonstrates a bug where the encoding for a 16-bit bswap prints a 16-bit register and a 32-bit mnemonic. Intel docs say 16-bit bswap is undefined. We should either claim it as an invalid encoding or we should print a 16-bit mnemonic.
objdump does print the encoding as bswap with a 16-bit register. But it doesn't seem to ever print a suffix.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@330621 91177308-0d34-0410-b5e6-96231b3b80d8
Three new instructions:
umonitor - Sets up a linear address range to be
monitored by hardware and activates the monitor.
The address range should be a writeback memory
caching type.
umwait - A hint that allows the processor to
stop instruction execution and enter an
implementation-dependent optimized state
until occurrence of a class of events.
tpause - Directs the processor to enter an
implementation-dependent optimized state
until the TSC reaches the value in EDX:EAX.
Also modifying the description of the mfence
instruction, as the rep prefix (0xF3) was allowed
before, which would conflict with umonitor during
disassembly.
Before:
$ echo 0xf3,0x0f,0xae,0xf0 | llvm-mc -disassemble
.text
mfence
After:
$ echo 0xf3,0x0f,0xae,0xf0 | llvm-mc -disassemble
.text
umonitor %rax
Reviewers: craig.topper, zvi
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D45253
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@330462 91177308-0d34-0410-b5e6-96231b3b80d8
The destination size of the movzx/movsx instruction is controlled by the normal operand size mechanisms. Only the input type is fixed.
This means that a 0x66 prefix on the encoding for zext/sext 16->32 should really produce a 16->16 instruction. Functionally this is equivalent to a GR16->GR16 move since bits 16 and above will be preserved. So nothing is actually extended.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@330078 91177308-0d34-0410-b5e6-96231b3b80d8
Hint to hardware to move the cache line containing the
address to a more distant level of the cache without
writing back to memory.
Reviewers: craig.topper, zvi
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D45256
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@329992 91177308-0d34-0410-b5e6-96231b3b80d8
Similar to the wbinvd instruction, except this
one does not invalidate caches. Ring 0 only.
The encoding matches a wbinvd instruction with
an F3 prefix.
Reviewers: craig.topper, zvi, ashlykov
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D43816
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@329847 91177308-0d34-0410-b5e6-96231b3b80d8
