The indirect function table, synthesized by the linker, is needed if and
only if there are TABLE_INDEX relocs.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
I have run CodeGen/WebAssembly, MC/WebAssembly, and lld/test/wasm tests, which pass. Split off from https://reviews.llvm.org/D90948.
Still has the bad aspect of doing function table symbol creation in MCContext. Will look deeper there tomorrow. Does this size of the change look OK to you, @sbc100 ?
This looks pretty much like I was suggesting, although I was hoping we could make it more isolated by just making the creation of the existing table import conditional rather than creating a new MC symbol.
llvm/lib/MC/WasmObjectWriter.cpp | ||
---|---|---|
506 | Can we just move the code below, or make it conditional to avoid the MCConteext changes? (i.e. can we make this change local to this file?) |
What I was hoping for here is minimal change to the object writer to remove the table from object files that don't reference it. This seem separable from the question of whether the indirection function table should be first class MC symbol .. although maybe I'm taking this CL splitting thing to far.
llvm/test/MC/WebAssembly/weak-alias.s | ||
---|---|---|
242 ↗ | (On Diff #305814) | Why did these changes occur? Do you have some tool to automatically updating the expected output? |
Just backing up a bit for context -- the end goal to add support to wasm-ld for linking object files that reference tables; pruning needless __indirect_function_table imports is a "side quest". To link tables, I need relocs for all table references written to object files, and linker symtab entries for all tables. Do you agree that a first-class MCSymbol is a part of that final pipeline? If so, I think we're on the good path here, and that using a different mechanism would just require more testing when we put the MCSymbol mechanism in place. Anyway, just a gentle argument that it seems to me that this is about the right patch size, though whether we have the symbol creation in MCContext is another question of course.
llvm/lib/MC/WasmObjectWriter.cpp | ||
---|---|---|
506 | We certainly can. However, with the next patch, we will need to call getOrCreateWasmDefaultFunctionTableSymbol from three places in Target/WebAssembly: the asm parser and from the two instruction selectors. Do you prefer to duplicate this code there? | |
llvm/test/MC/WebAssembly/weak-alias.s | ||
242 ↗ | (On Diff #305814) | I just checked and these changes are unnecessary. I will remove this change from this patch. What is going on here fwiw is that the weak-alias test will change when table numbers get encoded as 5-byte relocs, so this file was on the changeset for the TABLE_NUMBER patch. I updated that test by pasting in the output of the obj2yaml with the prefix. That's where these extraneous bits come in. When I removed the test changes corresponding to the TABLE_NUMBER patch, we're just left with this meaningless update. |
Yes, I was thinking we could just land the side quest (I like that term!) quickly without too much discussion. If you want to include the MCSymbol creation in addtion then I'm not averse to that.. but as you say, that means we have to figure if the target-independent MCContext is the right place for the two new function (getOrCreateWasmFunctionTableSymbol). My gut tells me it not, but I'm also no an expert in these areas... @tlively @aardappel might have some idea where the right place for this kind of thing is.
llvm/lib/MC/WasmObjectWriter.cpp | ||
---|---|---|
506 | In the end I think you are right and that in this patch, no need to muck with MCContext.h. If we should factor out a function, it will become obvious in future patches. |
llvm/lib/MC/WasmObjectWriter.cpp | ||
---|---|---|
503 | Perhaps add a TODO here since we probably don't to keep this here long right? |
llvm/lib/MC/WasmObjectWriter.cpp | ||
---|---|---|
503 | We keep this one, I think. Currently call_indirect has no relocs. In the future it will have TABLE_NUMBER relocs. TABLE_INDEX relocs will stay around, used for function pointers. In some future it might be useful to have the TABLE_INDEX relocs specify an "address space" in the form of a table number (table symbol reference); i.e. the EXTENDED_TABLE_INDEX reloc would be against both a function symbol and a table symbol. But until then, and until such a use case arises, I think TABLE_INDEX relocs still implicitly use __indirect_function_table. WDYT? | |
llvm/test/MC/WebAssembly/reloc-pic.s | ||
94 | This is the result of replacing the whole CHECK+CHECK_NEXT* block with the output of the command in question. Harmless AFAIU, but extraneous also, so I have removed it. | |
llvm/test/MC/WebAssembly/tables.s | ||
211 | I just checked and yes, they were here before and not being checked for. |
This patch doesn't seem to apply to the master branch of llvm.
It also says this when I run arc patch:
This diff is against commit e0257d84325828a4faddfaf48512358aa9681632, but the commit is nowhere in the working copy. Try to apply it against the current working copy state? (1a036e9cc82a7f6d6f4675d631fa5eecd8748784) [Y/n]
Perhaps you need to rebase?
Conflicts with https://reviews.llvm.org/D90930 apparently; will fix.
It also says this when I run arc patch:
This diff is against commit e0257d84325828a4faddfaf48512358aa9681632, but the commit is nowhere in the working copy. Try to apply it against the current working copy state? (1a036e9cc82a7f6d6f4675d631fa5eecd8748784) [Y/n]Perhaps you need to rebase?
Yeah the patch was on a local copy of the already-landed https://reviews.llvm.org/D91635. Will rebase,
llvm/lib/Object/WasmObjectFile.cpp | ||
---|---|---|
491 | We should probably get smarter about these over allocations now that we have so many different import types here. Unrelated to this CL though. |
Looks like we need one more rebase now that https://reviews.llvm.org/D91849 has landed.
done, thanks for your patience; MC, CodeGen, and lld WebAssembly tests checked and passing.
Perhaps add a TODO here since we probably don't to keep this here long right?