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

[Andy Wingo via Phabricator via llvm-commits]

wingo added a comment.

In D90948#2528695 <https://reviews.llvm.org/D90948#2528695>, @sbc100 wrote:

> In D90948#2527616 <https://reviews.llvm.org/D90948#2527616>, @wingo wrote:
>
>> 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?

Yes.  I thought it would be a stopgap mechanism but this would make it be more permanent, happening both for reftypes and non-reftypes binaries.

> 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?

No, the linker can be a bit more dumb than that -- it implies the existence of a table based on whether an input needs it.  MVP inputs declare that they need a table by having a table import.  An input needs the function table if it has an indirect call or a function pointer (bitcast).  The latter case coresponds to TABLE_INDEX relocs, but the former has no relocs in MVP inputs.

> 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).

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.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90948