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

[Sam Clegg via Phabricator via llvm-commits]

sbc100 added a comment.

In D90948#2527616 <https://reviews.llvm.org/D90948#2527616>, @wingo wrote:

> Thanks again for comments!
>
> I would like to preserve the property that allows the linker to omit `__indirect_function_table` if it is not needed.  Right now the linker has two ways it treats incoming files: if the input has table symtab entries, the input is assumed to have symbols for all tables and relocs for all table references.  Otherwise, if the input has tables (import or not) but no symbols, it is an MVP input which requires an indirect function table.  It would be sufficient to link the two if we ensure that the indirect function table is allocated table number 0.
>
> Is the suggestion that for reftypes objects, we would omit the symbol for `__indirect_function_table`, and omit relocations against it?  It would mean that the linker would have to grovel reftypes inputs for table imports that aren't in the symtab, in order to know if a reftypes object uses the indirect function table.  This is doable but it is less optimal: since the linker doesn't have a precise idea of where the indirect function table is used, it has to assume that if it's live in the input, it's live in the output.  If each table reference has a reloc, this isn't the case, and we can have more precise GC.  But given the tradeoffs, do you prefer that solution?

When you say "the linker would have to grovel reftypes inputs for table imports that aren't in the symtab" are you referring to the way things work today with MVP object files?    I can't remember exactly how the mechanism works but we currently have to imply the existence of the table based on TABLE_INDEX relocations right?    Sorry I've not been following all the comments here.  Are you saying you want to improve on the status quo (make this more precise), or are you concerned about a regression (i.e. becoming less precise about the GC of the table in the final output).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90948