[PATCH] D45848: [WebAssembly] Initial Disassembler.

Wouter van Oortmerssen via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu May 10 08:58:55 PDT 2018


aardappel added inline comments.


================
Comment at: lib/Target/WebAssembly/Disassembler/WebAssemblyDisassembler.cpp:170
+      case MCOI::OPERAND_REGISTER: {
+        // These are NOT actually in the instruction stream, but MC is going to
+        // expect operands to be present for them!
----------------
dschuff wrote:
> I think we will need to generate the register assignments, either here or in a post-processing step. I don't think it currently makes sense to have a second version of all the instructions with implicit operands (even though they wouldn't be needed by MC in explicit-locals mode).
> 
> You'd think it ought to be as simple as running a "pass" over the MCInsts, but  last I checked there wasn't really any facility for running passes over MC; it's structured much more like a stream. (and looking at the use of `getInstruction` in  e.g. LLVMDisasmInstruction in MCDisassembler or in llvm-objdump, it looks like the returned MCInsts just get passed directly through to the printer. We could maybe hang some state off of the WebAssemblyDisassembler?
Yes, we can easily keep a stack to track assignment + types in WebAssemblyDisassembler, but we'd be making the assumption that instructions are always disassembled in order. To accomodate this code being called for disassembling single instructions, this code would have to be "robust" and still function if the stack is empty etc.

More-over to get correct types we'd need access to locals/args, which we don't have. We currently don't even know where a function starts and stops.

Then, in table-gen there is currently one instruction per return type, i.e. i32.call vs i64.call, which are actually the same instruction. We'd either need to strip these types in a post-process, or we'd need to output more complicated tables that contain all of them, so the dissassembler can pick the right one based on stack type information, if it has any.

Since this isn't quite trivial, I suggest I land this basic disassembler (which will at least allow objdump etc to show something useful), then experiment with the above in follow-ups.


Repository:
  rL LLVM

https://reviews.llvm.org/D45848





More information about the llvm-commits mailing list