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

Sam Clegg via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Nov 9 08:06:03 PST 2020


sbc100 added a comment.

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

Let me see if  I summarize the pros/cons of uniformly adding relocations for all call_indirect:

Pros:

1. Single codegen path for call_indirect
2. Table 0 is no longer magical

Cons:

1. More work / relocations in each object file
2. More padding object files and unoptimized linker output
3. All objects (even non-ref-type-used ones) now contain new relocation types breaking backward compat of new objects with old tools.

Am I missing anything here?   Based on these arguments along I don't feel very strongly either way.    @sunfish might have an opinion here?


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