[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