This is an archive of the discontinued LLVM Phabricator instance.

[WebAssembly] Assembler/InstPrinter: support call_indirect type index.
ClosedPublic

Authored by aardappel on Jul 15 2019, 10:12 AM.

Details

Summary

A TYPE_INDEX operand (as used by call_indirect) used to be represented
by the InstPrinter as a symbol (e.g. .Ltype_index0@TYPE_INDEX) which
was a bit of a mismatch with the WasmObjectWriter which expects an
unnamed symbol, to receive the signature from and then turn into a
reloc.

There was really no good way to round-trip this information. An earlier
version of this patch tried to attach the signature information using
a .functype, but that ran into trouble when the symbol was re-emitted
without a name. Removing the name was a giant hack also.

The current version changes the assembly syntax to have an inline
signature spec for TYPEINDEX operands that is always unnamed, which
is much more elegant both in syntax and in implementation (as now the
assembler is able to follow the same path as the regular backend)

Diff Detail

Repository
rL LLVM

Event Timeline

aardappel created this revision.Jul 15 2019, 10:12 AM
Herald added a project: Restricted Project. · View Herald TranscriptJul 15 2019, 10:12 AM
aheejin added a comment.EditedJul 15 2019, 6:20 PM

Why should type_index symbols be unnamed, i.e., why does WasmObjectWriter try to ensure that they are unnamed? Can we possibly remove that constraints?

I think the problem here is that there is no such thing as a first class "type" symbol, there are only functions symbols that can be referenced with @TYPE_INDEX to find where they live in the type index space.

Do we need a first class "type" symbol? Perhaps we do? Also can call_indirect take a signature literal in the asm syntax. i.e. do we want to allow all of the following:

call_indirect some_function@TYPEINDEX
call_indirect some_type
call_indirect (i32) -> (i32)

Right now it seems like we are only supporting the first one, and this change basically declared a face function symbol to hang that type off of.

It seems clear that we *do* want to support populating the type section and referencing those types without declaring any functions at all. You can imagine a module that does all kind of call_indirect on an imported table without actually declaring any functions at all. So I think I'm arguing that we a first calls type symbol as well as the some_function@TYPEINDEX syntax.

lib/Target/WebAssembly/MCTargetDesc/WebAssemblyInstPrinter.cpp
58 ↗(On Diff #209900)

This seems like this should be unnecessary.

The only types of symbols that can be referenced with VK_WASM_TYPEINDEX are function symbols. i.e. should be able to assert here that SRE->getSymbol is a function symbo.l. And functions symbols should already if their type specified in the assembly when they are declared.

lib/Target/WebAssembly/MCTargetDesc/WebAssemblyInstPrinter.h
62 ↗(On Diff #209900)

Seems a little odd to have these two "ToString" functions return std::string but the two above return C strings.

aardappel updated this revision to Diff 212028.Jul 26 2019, 5:06 PM

Reworked to use inline signatures.

aardappel marked 2 inline comments as done.Jul 26 2019, 5:11 PM

@sbc100 @aheejin and others: code has been reworked and is much more elegant.. no more hacks.

lib/Target/WebAssembly/MCTargetDesc/WebAssemblyInstPrinter.cpp
58 ↗(On Diff #209900)

I'm not sure what you mean, since not all function symbols are a TYPEINDEX. Either way, this code has been reworked.

lib/Target/WebAssembly/MCTargetDesc/WebAssemblyInstPrinter.h
62 ↗(On Diff #209900)

The const char * ones are because, well, the strings are compile-time constant, and the std::string ones since they construct a string. I wouldn't want to change the former to std::string also for consistency, as this forces an allocation on the caller they may not need.

aardappel edited the summary of this revision. (Show Details)Jul 26 2019, 5:12 PM
tlively accepted this revision.Jul 30 2019, 11:03 PM

This looks great! The code is straightforward and I like the extra information in the text format. We will have to do a little more work to support return_call_indirect, but it looks like doing so should be fairly straightforward on top of this base.

lib/Target/WebAssembly/AsmParser/WebAssemblyAsmParser.cpp
495 ↗(On Diff #212028)

We should add return_call_indirect support as well, but probably in a separate CL.

This revision is now accepted and ready to land.Jul 30 2019, 11:03 PM
tlively added inline comments.Jul 31 2019, 10:51 AM
lib/Target/WebAssembly/AsmParser/WebAssemblyAsmParser.cpp
495 ↗(On Diff #212028)

Actually, there should be no different work to do for return_call_indirect because the text format should contain the correct return type. So it would be good to add that case to this condition now.

aardappel updated this revision to Diff 212853.Aug 1 2019, 10:40 AM

Added return_call_indirect

aardappel marked 2 inline comments as done.Aug 1 2019, 10:41 AM
aardappel updated this revision to Diff 212857.Aug 1 2019, 11:06 AM

Fixed tail-call-encodings.s test

This revision was automatically updated to reflect the committed changes.