[PATCH] Alternative way of representing comdats
David Majnemer
david.majnemer at gmail.com
Tue Jun 24 10:31:54 PDT 2014
================
Comment at: docs/LangRef.rst:732
@@ +731,3 @@
+specify this key will only end up in the final object file if the linker chooses
+that key over some other key.
+
----------------
Rafael Ávila de Espíndola wrote:
> Other set of objects/sections with that key.
>
> "the linker" in here is a bit ambiguous. Are we talking about the system linker or lib/Linker. Since we produce relocatable objects, it is probably better to state this in terms of what we do: put the global objects in a section with that comdat.
>
The objects aren't in the same section. In COFF, they are in different sections which are associated.
================
Comment at: docs/LangRef.rst:734
@@ +733,3 @@
+
+Note that the Mach-O platform doesn't support COMDATs and ELF only supports
+``any`` as a selection kind.
----------------
Rafael Ávila de Espíndola wrote:
> Move this after the part the defines what the selection kind is maybe?
Done.
================
Comment at: docs/LangRef.rst:761
@@ +760,3 @@
+
+Note that not all targets support COMDATs and some may only support ``any`` as a
+selection kind.
----------------
Rafael Ávila de Espíndola wrote:
> This paragraph is now redundant.
Done.
================
Comment at: docs/LangRef.rst:763
@@ +762,3 @@
+selection kind.
+
+Here is an example of a COMDAT group where a function will only be selected if
----------------
Rafael Ávila de Espíndola wrote:
> There are still some things should probably be mentioned:
>
> * We split "IR level sections" into multiple sections in the final .o since in object files you can't have a section that is part in one comdat and part in another.
> * Explain how we map mulitple sections with the same comdat to using associative comdts on COFF. Otherwise someone is sure to look at the list and think associative is missing :-)
> * Alias are placed in the same comdat the aliasee computes to, if any.
I did the last two, I don't quite understand the first one.
================
Comment at: include/llvm/IR/GlobalValue.h:115
@@ +114,3 @@
+ bool hasComdat() const { return getComdat() != nullptr; }
+ Comdat *getComdat() {
+ return const_cast<Comdat *>(
----------------
Rafael Ávila de Espíndola wrote:
> This looks odd. You probably want the const version to forward to the non-const:
>
> return const_cast<GlobalValue*>(this)->getComdat();
>
Done.
================
Comment at: include/llvm/Support/GCOV.h:369
@@ +368,3 @@
+ BranchesExec(0), BranchesTaken(0) {}
+ GCOVCoverage(StringRef Name)
+ : Name(Name), LogicalLines(0), LinesExec(0), Branches(0),
----------------
Rafael Ávila de Espíndola wrote:
> unrelated change?
Done.
================
Comment at: lib/CodeGen/TargetLoweringObjectFileImpl.cpp:252
@@ -242,4 +251,3 @@
!Kind.isCommon()) {
- const char *Prefix;
- Prefix = getSectionPrefixForGlobal(Kind);
+ StringRef Prefix = getSectionPrefixForGlobal(Kind);
----------------
Rafael Ávila de Espíndola wrote:
> Nice cleanup. You can commit this now if you want.
Done in r211601.
================
Comment at: lib/CodeGen/TargetLoweringObjectFileImpl.cpp:844
@@ -781,1 +843,3 @@
+ if ((GV->isWeakForLinker() || EmitUniquedSection || GV->hasComdat()) &&
+ !Kind.isCommon()) {
const char *Name = getCOFFSectionNameForUniqueGlobal(Kind);
----------------
Rafael Ávila de Espíndola wrote:
> Reminds me: we should probably reject GlobalObject with common linkage and an explicit comdat in the verifier.
Done.
================
Comment at: lib/Linker/LinkModules.cpp:542
@@ -536,1 +541,3 @@
+static GlobalValue *getComdatLeader(Module *M, StringRef ComdatName) {
+ GlobalValue *GV = M->getNamedValue(ComdatName);
----------------
Rafael Ávila de Espíndola wrote:
> Not sure I follow. Is this assuming that the comdat name is related to the name of a global? That may be a common use but is not in any way required by the semantics.
>
The COMDAT name **is** related to the name of the global when the selection kind isn't `any`.
================
Comment at: lib/Linker/LinkModules.cpp:558
@@ +557,3 @@
+ if (DstC && SrcC) {
+ Comdat::SelectionKind DSK = DstC->getSelectionKind();
+ Comdat::SelectionKind SSK = SrcC->getSelectionKind();
----------------
Rafael Ávila de Espíndola wrote:
> I assume this logic matches what the COFF linker does? Can you extract it to a helper like
>
> bool computeResultingSeelectionKind(Comdat::SelectionKind &Result, Comdat::SelectionKind &Src, Comdat::SelectionKind &Dst) ...
>
> and put a comment saying where the merging logic comes from.
Done.
================
Comment at: lib/Linker/LinkModules.cpp:583
@@ +582,3 @@
+ case Comdat::SelectionKind::Newest:
+ // Go with src
+ LinkFromSrc = true;
----------------
Rafael Ávila de Espíndola wrote:
> This is fairly arbitrary for Newest. We should probably error or actually check the bitcode timestamp, no?
Done.
================
Comment at: lib/Linker/LinkModules.cpp:595
@@ +594,3 @@
+
+ const auto SrcGV = dyn_cast<GlobalVariable>(SrcGVLeader);
+ const auto DstGV = dyn_cast<GlobalVariable>(DstGVLeader);
----------------
Rafael Ávila de Espíndola wrote:
> "auto *" instead of "auto" is probably better since it makes it obvious it is a pointer.
Done.
================
Comment at: lib/Linker/LinkModules.cpp:626
@@ +625,3 @@
+ return emitError("Linking COMDATs named '" + ComdatName +
+ "': ExactMatch requries GlobalVariable");
+ }
----------------
Rafael Ávila de Espíndola wrote:
> Not just ExactMatch.
Done.
================
Comment at: lib/Linker/LinkModules.cpp:865
@@ +864,3 @@
+ bool LinkFromSrc = false;
+ Comdat *DC = nullptr;
+ if (const Comdat *SC = SGV->getComdat()) {
----------------
Rafael Ávila de Espíndola wrote:
> BTW, do we produce as error if we have
>
> module1:
>
> @a = ... comdat $c1, largest
>
> module2
>
> @b = ... comdat $c1, newest
>
> that is, we have conflicting comdat selection kinds, but the comdats never show up in the corresponding global objects.
>
There is code for this:
return emitError("Linking COMDATs named '" + ComdatName +
"': invalid selection kinds!");
http://reviews.llvm.org/D4178
More information about the llvm-commits
mailing list