[Parser] Start to parse instructions #4789
Conversation
Update gen-s-parser.py to produce a second version of its parsing code that
works with the new wat parser. The new version automatically replaces the `s`
element argument in the existing parser with the `ctx` and `in` arguments used
by the new parser, so adding new instructions will not require any additional
work in gen-s-parser.py after this change.
Also add stub `make***` functions to the new wat parser, with a few filled out,
namely `makeNop`, `makeUnreachable`, `makeConst`, and `makeRefNull`. Update the
`global` parser to parse global initializer instructions and update
wat-kitchen-sink.wast to demonstrate that the instructions are parsed correctly.
Adding new instruction classes will require adding a new `make***` function to
wat-parser.cpp in additional to wasm-s-parser.{h,cpp} after this change, but
adding a trivial failing implementation is good enough for the time being, so I
don't expect this to appreciably increase our maintenance burden in the near
term.
The infrastructure for parsing folded instructions, instructions with operands,
and control flow instructions will be implemented in future PRs.
|
Current dependencies on/for this PR: This comment was auto-generated by Graphite. |
| Result<typename Ctx::GlobalTypeT> globaltype(Ctx&, ParseInput&); | ||
|
|
||
| // Instructions | ||
| template<typename Ctx> |
There was a problem hiding this comment.
These declarations could be autogenerated using an include of wasm-delegations.def
There was a problem hiding this comment.
This would be tricky because some of them have extra arguments, such as the calls with their isReturn arguments, i31 and struct get operations with their signed_ argument, and various other instructions with operation arguments.
There was a problem hiding this comment.
Could we get the isReturn from the name, if we read it again? Or is it lost at that point?
There was a problem hiding this comment.
(In the old parser that was possible, though not sure if we actually used that ability or not)
There was a problem hiding this comment.
Right now the names are lost, but we could have the generated code pass the names into the parsing functions as additional arguments. I'm not sure generating the declarations would really save us much work though, since I don't see a way to generate the definitions as well.
| } else { | ||
| return Ok{}; | ||
| } | ||
| } |
There was a problem hiding this comment.
Does SFINAE or such let us write a template def more than once? if so we could emit a failing stub for all the instructions (using wasm-delegations.def) and then just add the working ones after that.
There was a problem hiding this comment.
No, you can't define the same template twice, unfortunately.
Update gen-s-parser.py to produce a second version of its parsing code that
works with the new wat parser. The new version automatically replaces the
selement argument in the existing parser with the
ctxandinarguments usedby the new parser, so adding new instructions will not require any additional
work in gen-s-parser.py after this change.
Also add stub
make***functions to the new wat parser, with a few filled out,namely
makeNop,makeUnreachable,makeConst, andmakeRefNull. Update theglobalparser to parse global initializer instructions and updatewat-kitchen-sink.wast to demonstrate that the instructions are parsed correctly.
Adding new instruction classes will require adding a new
make***function towat-parser.cpp in additional to wasm-s-parser.{h,cpp} after this change, but
adding a trivial failing implementation is good enough for the time being, so I
don't expect this to appreciably increase our maintenance burden in the near
term.
The infrastructure for parsing folded instructions, instructions with operands,
and control flow instructions will be implemented in future PRs.