This adds COMDAT support to the LLVM frontend and Wasm object-file support.
For spec, see https://github.com/WebAssembly/tool-conventions/pull/31
For corresponding LLD change, see https://bugs.llvm.org/show_bug.cgi?id=35533, and D40845
Paths
| Differential D40844
[WebAssembly] COMDAT: core LLVM support ClosedPublic Authored by ncw on Dec 5 2017, 10:28 AM.
Details Summary This adds COMDAT support to the LLVM frontend and Wasm object-file support. For spec, see https://github.com/WebAssembly/tool-conventions/pull/31 For corresponding LLD change, see https://bugs.llvm.org/show_bug.cgi?id=35533, and D40845
Diff Detail
Event TimelineHerald added subscribers: sunfish, aheejin, dschuff, jfb. · View Herald TranscriptDec 5 2017, 10:28 AM Comment Actions Thanks for doing this. Looks like a good direction!
Comment Actions OK, I've cleaned this up, and I think it's ready to go.
Now, the contentious bit - is it actually the right design to be using ELF-style COMDAT? Well, I think it _maybe_ is, and it's better than nothing. I think we basically need to just keep on improving LLD, and as we go we'll add more flags and bits and pieces as needed. LLD linking is a bit different to x86 linking, certainly when we start doing more clever dead code removal, and I don't want to anticipate that too much. I think there's value in merging a simple implementation soon, and improving it. Anything more fancy than the COMDAT support I've done here, would require a correspondingly more fancy/complicated initial review on the LLD side. Comment Actions Update - added "flags" field and removed explicit Comdat for globals, following Dan's comments on the GitHub PR. ncw added inline comments.
Comment Actions Based on the discussion in the bug (https://bugs.llvm.org/show_bug.cgi?id=35533) it sounds like we need to take a look at SHF_LINK_ORDER and how that works. It sounds like its different to the "group" concept. But if we do decide groups are the way to go this change lgtm. Comment Actions Changes:
Comment Actions
I've added a looong comment to that bug. SHF_LINK_ORDER really is very very similar to "Comdat groups" - the only differences are 1) ELF historical encoding stuff, and 2) SHF_LINK_ORDER creates "anonymous" linker groupings rather than named Comdat groups. I basically can't see what all the fuss is about! Comdat "groupings" are what we want, and all the alternatives we're discussing provide the same semantic. It's just arguing about the name and the details? Maybe if you've been working on this for a while though the details seem bigger. I can't see a major functional difference between what I've implemented here, and what SHF_LINK_ORDER would provide. I might be missing something though....
ncw retitled this revision from Wasm COMDAT: core LLVM support to [WebAssembly] COMDAT: core LLVM support.Dec 20 2017, 8:08 AM Comment Actions I'm behind on some of the discussions on this topic at the moment, but overall, this looks like it's headed in a good direction, so I'm in favor of this patch. This revision is now accepted and ready to land.Jan 5 2018, 2:25 AM Comment Actions Thanks! Rebased. NB. I haven't yet re-run the tests, this is an optimistic update - it takes a looong time to compile everything, and after a rebase pretty much everything needs to recompile. Just building the tests now. Comment Actions MC tests pass, but I've just noticed I missed one in CodeGen/WebAssembly/comdat.ll. I won't be able to fix it today, sorry.. Closed by commit rL322135: [WebAssembly] Add COMDAT support (authored by sbc). · Explain WhyJan 9 2018, 3:44 PM This revision was automatically updated to reflect the committed changes.
Comment Actions When testing with lld I noticed that the comdat group names are appearing as undefined symbols in the final output. See: https://reviews.llvm.org/D41959 I this case it results in unresolved symbol: sharedComdat Can you think of a way to avoid including these?
Revision Contents
Diff 129128 docs/LangRef.rst
include/llvm/ADT/Triple.h
include/llvm/BinaryFormat/Wasm.h
include/llvm/Object/Wasm.h
include/llvm/ObjectYAML/WasmYAML.h
lib/CodeGen/TargetLoweringObjectFileImpl.cpp
lib/MC/WasmObjectWriter.cpp
lib/Object/WasmObjectFile.cpp
lib/ObjectYAML/WasmYAML.cpp
test/MC/WebAssembly/comdat.ll
tools/obj2yaml/wasm2yaml.cpp
tools/yaml2obj/yaml2wasm.cpp
|
Why a new struct here but not for Function and Segment?
If we decide a new struct is needed, we have tended to prefer composition over inheritance for this kind of thing.