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

[Andy Wingo via Phabricator via llvm-commits]

wingo marked 3 inline comments as done.
wingo added a comment.

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

> Regarding always generating relocations for call_indirect..    I'm not so much worried about the extra space it would take, but it does seem like unnecessary work for the linker to be doing.   Are you sure they are less common than other relocation types?  Do you have evidence of this?

I don't have a really representative corpus, but if you consider the old epic zen garden demo, only 6.8% of call sites are `call_indirect`.   Tested via `wasm-objdump -d $file | grep -c call_indirect` and dividing that by `grep -c call`.

> I'm also totally fine with table 0 being special, and indeed I think that linker is going to always have to treat memory 0 and table 0 as special (or at least it will always need to be aware of which table/memory is the special one).

Right now with the MVP, there will only ever be at most one table, so it will always get allocated to 0 -- no problem.  If we ever have a use case for multiple function tables synthesized by the linker, perhaps for CFI reasons, perhaps we'd need another kind of reloc -- i.e. `TABLE_INDEX`, but with respect to a specific indirect function table.

I agree with your assessment of pros and cons of always emitting `TABLE_NUMBER` relocs btw.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90948