[PATCH] D55149: [WebAssembly] Enforce assembler emits to streamer in order.

Wouter van Oortmerssen via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Dec 3 11:58:09 PST 2018


aardappel marked 5 inline comments as done.
aardappel added inline comments.


================
Comment at: lib/Target/WebAssembly/AsmParser/WebAssemblyAsmParser.cpp:161
       : MCTargetAsmParser(Options, STI, MII), Parser(Parser),
-        Lexer(Parser.getLexer()) {
+        Lexer(Parser.getLexer()), CurrentState(FileStart), LastLabel(nullptr) {
     setAvailableFeatures(ComputeAvailableFeatures(STI.getFeatureBits()));
----------------
dschuff wrote:
> aardappel wrote:
> > aheejin wrote:
> > > Nit: Can we use C++11-style in-class initialization for these two variables?
> > Sure.. I guess I was being conservative, not knowing what level of C++ I can use.
> In LLVM, we love ALL the C++! but there's still those pesky older versions of compilers, distros, etc. see https://llvm.org/docs/CodingStandards.html#languages-libraries-and-standards . See also http://lists.llvm.org/pipermail/llvm-dev/2018-October/127045.html
Yes, I use C++17 on some projects, C++0x (pre-C++11) on others, so I tend to get confused on what I can use. I'll re-read that section to remind myself :)


================
Comment at: lib/Target/WebAssembly/AsmParser/WebAssemblyAsmParser.cpp:408
+        CurrentState = FunctionStart;
+      }
       auto Signature = make_unique<wasm::WasmSignature>();
----------------
aardappel wrote:
> sbc100 wrote:
> > aardappel wrote:
> > > This code is not super elegant, but kinda has to be this way because we have .functype which both introduces a function and ones which just declare external ones. Now if you misspel a label you'll fail to start a new function. 
> > > 
> > > More ideal would be split these, and have a .functype with no name that annotates the start of a function (and the assembler enforces only comes after a label) and a different one, e.g. .funcdecl, that does have its own name and is only used for external types. Not sure if such a refactoring is worth it though, after we just re-did all the tests with .functype.
> > I like the repeated name in the .functype directive because it seems to match existing assembly directives.
> > 
> > If we want to distinguish between types for internal vs external functions perhaps we would want a new directive such as ".extern_functype" but as you say I'm not sure its worth it. 
> Also note that in the past we decided that we like the assembler to be relatively "dumb", in terms of not needing to have a lot of structural knowledge about wasm. Turns out that is not possible with how streamers work, we need the assembler to enforce a certain level of structure.
Ok, will leave it as-is unless anyone else feels strongly about it.


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D55149/new/

https://reviews.llvm.org/D55149





More information about the llvm-commits mailing list