[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