[PATCH] D56092: [WebAssembly] made assembler parse block_type
Heejin Ahn via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Tue Jan 1 23:04:33 PST 2019
aheejin added a comment.
In D56092#1341055 <https://reviews.llvm.org/D56092#1341055>, @aardappel wrote:
> Note to reviewers: I can fix the FIXME in the disassembler by making it a proper SLEB, and change the WebAssembly::ExprType enum to have negative values as per the spec. I think that should have little impact as the backend treats these values as opaque, afaik.. though maybe I am missing something. Happy to put that in this CL or a next one.
I think there's a discrepancy between what the github binary encoding doc <https://github.com/WebAssembly/design/blob/master/BinaryEncoding.md#language-types> says and what the official spec <https://webassembly.github.io/spec/core/binary/types.html#value-types> says. The official spec lists them explicitly as single byte values and not LEB, and I think we should follow the official spec. Actually, they had been listed as signed values but changed to single byte values earlier this year by these CLs (CL1 <https://reviews.llvm.org/D43921>, CL2 <https://reviews.llvm.org/D43922>, and CL3 <https://reviews.llvm.org/D43991>).
================
Comment at: lib/Target/WebAssembly/AsmParser/WebAssemblyAsmParser.cpp:303
+ WebAssembly::ExprType parseBlockType(StringRef id) {
+ return StringSwitch<WebAssembly::ExprType>(id)
----------------
Nit: `id` should be `Id` or `ID`, according to the LLVM coding style
================
Comment at: lib/Target/WebAssembly/AsmParser/WebAssemblyAsmParser.cpp:463
+ addBlockTypeOperand(Operands, NameLoc, BT);
+ Parser.Lex();
+ } else {
----------------
When do we need this `Parser.Lex()` and when we don't? This exists only in `if (ExpectBlockType)` side, so I'm curious.
================
Comment at: lib/Target/WebAssembly/AsmParser/WebAssemblyAsmParser.cpp:522
+ // Support blocks with no operands as default to void.
+ addBlockTypeOperand(Operands, NameLoc, WebAssembly::ExprType::Void);
}
----------------
It looks like we assume no signature as void, but all lines in the test case now have type signatures. Can we also have block/loop/try with no signatures?
================
Comment at: lib/Target/WebAssembly/Disassembler/WebAssemblyDisassembler.cpp:176
+ // FIXME: SLEB operand (according to spec) that is stored as uint8_t in
+ // MCInst.
+ case WebAssembly::OPERAND_SIGNATURE: {
----------------
This sentence sounds weird... perhaps a stray 'that'?
================
Comment at: lib/Target/WebAssembly/MCTargetDesc/WebAssemblyMCTargetDesc.h:350
+ AnyFunc = 0x70,
+ Func = 0x60,
+ ExceptRef = 0x68,
----------------
What is the difference between anyfunc and func?
Anyway, the current spec says [[ https://github.com/WebAssembly/design/blob/master/BinaryEncoding.md#block_type | `block_type` ]] should be either one of [[ https://github.com/WebAssembly/design/blob/master/BinaryEncoding.md#value_type | `value_type` ]] s or void, so I think that means anyfunc or func should not be allowed as a block type. [[ https://github.com/WebAssembly/exception-handling/blob/master/proposals/Exceptions.md#value_type | `except_ref` should be allowed ]] as a value type for the EH proposal though.
Repository:
rL LLVM
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D56092/new/
https://reviews.llvm.org/D56092
More information about the llvm-commits
mailing list