Page MenuHomePhabricator

Refactor WasmSignature and use it for MCSymbolWasm

Authored by dschuff on Sep 26 2018, 5:18 PM.



MCContext does not destroy MCSymbols on shutdown. So, rather than putting SmallVectors (which may heap-allocate) inside MCSymbolWasm, use unowned pointer to a WasmSignature instead. The signatures are now owned by the AsmPrinter.
Also uses WasmSignature instead of param and result vectors in TargetStreamer, and leaves some TODOs for further simplification.

Diff Detail

Event Timeline

dschuff created this revision.Sep 26 2018, 5:18 PM
dschuff planned changes to this revision.Sep 26 2018, 5:18 PM

Generally looks ok to me


Commented-out code (encapsulated in addSignature)


Intuitively, it feels odd to say 4 results, 1 param.


Instead of...?

Yeah sorry this still needs some cleanup before it's ready for review (also I need to post the lld side) . arc's --plan-changes flag claims to upload without requesting review (and it does) but unfortunately it doesn't suppress the herald rules :/

Ah, yeah I saw "dschuff planned changes to this revision." in phabricator and wasn't entirely sure what that meant, but didn't let that slow me down

dschuff updated this revision to Diff 167358.Sep 27 2018, 11:51 AM
  • cleanup
  • Use WasmSignature directly in DenseMap
dschuff updated this revision to Diff 167362.Sep 27 2018, 12:03 PM
  • Make argument order consistent
dschuff retitled this revision from [WIP] Refactor use of signatures and store them on the AsmPrinter to Refactor WasmSignature and use it for MCSymbolWasm.Sep 27 2018, 12:03 PM
dschuff edited the summary of this revision. (Show Details)
dschuff marked 3 inline comments as done.
sunfish added inline comments.Sep 27 2018, 12:21 PM

With this patch as it is now, the WasmStreamer's emitParam no longer does anything, but the AsmStreamer does. This weakens the mental model of the AsmPrinter somewhat, because code like EmitFunctionBodyStart here is conceptually supposed to be "emitting assembly code" through directives, with those directives mapping to either emitting the actual text for the directives, or implementing the directives directly in binary. This mental model is useful for keeping the codegen to object file path in sync with the AsmParser to object file path.

Since I don't see a call to setSignature in the AsmParser to object file path, is it not currently supporting signatures with this patch?

Generally looks good. Yay for unblocking us from leaving experimental


So we were just using 1 and 2 here as integers that happen to not be wasm value types?


Maybe makes sense to move this to lib/BinaryFormat/Wasm.cpp now? Since the other ToString methods for the bin format live there. Although perhaps its good to have all the assembly string constants here?

Seems a little odd that the exact save strings are returned by the above function, maybe they can be unified somehow?


Why not set the type of FUNCTION in setSignature()? And assert here maybe for sanity check?


I suppose this rename could be a separate NFC? Although maybe not worth it.


Should we assert there that size() <= 1?

dschuff marked an inline comment as done.Sep 27 2018, 3:43 PM
dschuff added inline comments.

Yeah, it looks that way.


Yeah probably ExprType and ValType could be unified. There is maybe a little bit better organization or separation we could have between the raw enums in BinaryFormat/Wasm.h and ValType (and MVT), but I tried to keep that to a minimum for this CL. Also I don't know why the BinaryFormat functions are in namespace wasm and the other stuff is in namespace WebAssembly.

Maybe for now we can keep them here (so at least the strings in the data section can stay unified) and then fix the above in a follow-up.


For every other case it's set in EmitSymbolAttribute. Indirect function type directives are just weird because the symbol we are emitting corresponds to an undefined function. This is another thing we might rethink now that s2wasm is gone and we just have our own asm parser and printer to coordinate.


Yeah I agree this is weird and should be fixed, although I decided not to take that any further for this CL. We can probably replace both of them with something else (i.e. different scheme of assembler directives) if that makes more sense. I had actually forgotten that there was even AsmParser support for .param directives, since the assembly language is still in flux and we aren't actually using it anywhere right now.

And come to think of it we'll have to handle the ownership of signatures similarly (i.e. outside of the MCContext, perhaps on the AsmParser).

I think what we'll want to do is get rid of the separate .param and .result directives in favor of a full signature specifier; something more like what we have already for .functype (but make it able to handle multiple returns). I don't know of anywhere we'd need to use just params or just results. Not sure if it's better to do that in a followup CL (better for review, but would undo a bit of this CL) or pack it into this one.


done in rL343275

dschuff updated this revision to Diff 167575.Sep 28 2018, 6:04 PM
  • Merge branch 'master' into signatures
  • add assert
  • Don't compute signature in EmitEndOfAsmFile if one is already there
  • Handle SRet in ComputeSignatureVTs
  • Fix -Wcovered-switch-default
  • Use ComputeSignatureVTs in more places



OK, I went further on this, and it's better. I think we should go all the way and remove the separate .param/.result but that requires changing all the tests, so it should be a separate CL.

dschuff updated this revision to Diff 167578.Sep 28 2018, 7:21 PM
  • clang-format

@sbc100 or @sunfish, any more comments?

sunfish accepted this revision.Oct 3 2018, 2:34 PM

LGTM. In the future it's possible we could need to hold the signatures somewhere other than the AsmPrinter, however we can figure that out later, when it's more clear what the MC AsmParser layer will need.

This revision is now accepted and ready to land.Oct 3 2018, 2:34 PM
dschuff closed this revision.Oct 9 2018, 4:09 PM

This was landed in rL343733. not sure why it didn't close already.

I tried to added .functype parsing support to WebAssemblyAsmParser and it involves calling MCSymbolWasm::setSignature from WebAssemblyAsmParser. I guess we should move the ownership to somewhere else. Here is the bug report for .functype handling.