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

[Andy Wingo via Phabricator via llvm-commits]

wingo added a comment.

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

> I'm beginning to (re-)wonder if we should leave the current "call_indirect" as special in that it always implicitly refers the magic table zero..  then we would introduce a new instruction for `call_indirect_explict` that could be used if and only if reference types is enabled and would have the relocation.   Data and function addresses will always be special in llvm so I think its OK to reflect that if it makes things simpler.   I guess it would make things simpler in some ways and more complex in other?   (Sorry if I'm re-litigating prior decisions here).

I am having a hard time seeing what a new instruction would buy us.  I would think there is already a sufficiently clear difference between `call_indirect` with an immediate table operand -- which was the case before I started, and is still the case now if reference-types is disabled -- and `call_indirect` with a symbol reference.  There would only need to be a relocation in the latter case.

In D90948#2526457 <https://reviews.llvm.org/D90948#2526457>, @tlively wrote:

> I like the idea of treating table zero as a magical table that is assumed to always exist and that all "normal" function pointers and indirect calls implicitly refer to, even when reference-types is enabled. That's how the table used to work, right? This would solve the problem of making sure the table is live when there are call_indirects or function pointers present in an object -- table 0 would always be live.

I think this goes against what was already done in D91637 <https://reviews.llvm.org/D91637> and D92840 <https://reviews.llvm.org/D92840>.  If individual object files can signal their use of the indirect function table via the presence or absence of the `__indirect_function_table` import, the linker can then only include it in the final linking stage when needed -- a minor win.  I can see the point in treating `__indirect_function_table` as a good default, and which in the absence of reference-types will be table number 0, but reserving table 0 only complicates things when reference types *are* enabled -- because then you have two kinds of tables.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90948