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

Thomas Lively via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Jan 27 14:26:59 PST 2021


tlively added a comment.

Thanks for your thoughtful answers, @wingo!

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 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. Then table symbols would only be used for additional user-defined tables from @pmatos's work, so they would only be used at all when reference-types is enabled. I don't think we even need a new kind of `call_indirect` instruction for this, since we will be able to differentiate "normal" indirect calls to table zero from other indirect calls by the address space of the called function pointer.


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