[PATCH] D90948: [WebAssembly] call_indirect issues table number relocs

Thomas Lively via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Jan 29 11:35:57 PST 2021


tlively added a comment.

Ah tricky. I understand why we can't just look at whether the table would have any non-null contents now. Thanks for explanations!

> AFAIU Thomas was initially suggesting always reserving table 0 -- always having a table import in input object files, the linker always includes a table in the output.  Then no symbols or relocations are needed to refer to the indirect function table; it's just assumed that the linker will assign it table number 0.  I was saying that as long as inputs signal their need for a table, the linker shouldn't have to write a table output.  The linker would just have to assign table number 0 to __indirect_function_table, if it is there; otherwise table 0 could be assigned to no table at all, if there are no tables, or some other table, for reftypes inputs that declare other tables.
>
> If this works for you all I can hack this up.  Will be Monday though as I have a day of meetings today.

Yes, this sounds good, although you're right that purely using the imports is not as precise as using relocations because they don't allow the linker to GC unnecessary tables. What do you think about this scheme:

- MVP object files signal table usage by importing or not importing a table.
- Reftypes object files signal table usage by a table symbol and relocations, even for the default table (table 0).
- The linker emits table zero if any non-reftypes object imports a table **or** if the default table symbol is live.

This scheme has the following valuable properties:

- The MVP object file ABI is not changed. MVP object files do not use new symbol or relocation types.
- MVP and reftypes object files can be linked together.
- If all objects that use the default table have reftypes enabled, we get the full precision of emitting the table only if its symbol is live.
- All feature detection happens in codegen, not in object writing.

I know this has somewhat come full circle and this scheme is close to what you've already implemented. Thanks for bearing with me as I've wrapped my head around all the issues!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90948



More information about the llvm-commits mailing list