[PATCH] D79672: [COFF] Move type merging to TpiSource::mergeDebugT virtual method

Reid Kleckner via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed May 13 13:36:31 PDT 2020


rnk marked 5 inline comments as done.
rnk added a subscriber: blackhole12.
rnk added inline comments.


================
Comment at: lld/COFF/DebugTypes.cpp:88
+    if (!f->pchSignature || !*f->pchSignature)
+      fatal(toString(f) + " claims to be a precompiled headers object, but "
+                          "does not have a valid signature!");
----------------
aganea wrote:
> rnk wrote:
> > aganea wrote:
> > > We will need tests for these I think. Same for the other `fatal` below.
> > I did this with obj2yaml -> sed -> yaml2obj. It works, but it's fragile.
> There's also `Inputs/precomp-invalid.obj` which is a copy of `precomp.obj` (I think) but with a different signature. So maybe this was already covered?
That one seems to cover a slightly different edge case. It has a valid S_OBJNAME record and signature, so we don't come to this `fatal` call.


================
Comment at: lld/COFF/DebugTypes.cpp:94
+      fatal(
+          "a PCH object with the same signature has already been provided (" +
+          toString(it.first->second->file) + " and " + toString(file) + ")");
----------------
aganea wrote:
> Could you please ensure this `fatal` codepath is covered? It should be, just to be sure.
Yep, it's already covered. The test just `cp`s the PCH object and links it twice.


================
Comment at: lld/COFF/DebugTypes.cpp:124
 
-TpiSource::TpiSource(TpiKind k, const ObjFile *f) : kind(k), file(f) {}
+static std::vector<std::unique_ptr<TpiSource>> gc;
 
----------------
aganea wrote:
> @santagada reported a 0.5 sec delay at shutdown, for a 800 MB .PDB, just for releasing allocated memory.
> 
> Do you think we can attach `gc` to the `PDBLinker` instead instead of it being `static`?
> 
> The goal would be after to integrate https://github.com/santagada/llvm-project/commit/5c8a17bbd2d7d7717f9c017e082cd37b0abbe52d
Hm, this reminds me, I seem to recall that there is a user who complains every time we add these global lists. Oh yeah: D70378 @blackhole12

In any case, I can confirm I saw @santagada's issues, I made this change recently:
rG2868ee5b3273e203d3b5d170531ecba764b2d610
We were destroying the BumpPtrAllocator used for PDB linking, instead of using the global one, which is not destroyed.


================
Comment at: lld/COFF/DebugTypes.cpp:352
+  if (expectedInfo->getGuid() != typeServerDependency.getGuid() ||
+      expectedInfo->getAge() != typeServerDependency.getAge())
+    return createFileError(
----------------
aganea wrote:
> I'm not sure we need to check the 'Age' here. In a incremental build, the .OBJ pointing to the /Zi .PDB might not change, but the .PDB will change, incrementing its 'Age'. I think the only this that matters is the Guid.
OK, I'll remove it. I noticed this was a functional change, I had to update one of the tests.


================
Comment at: lld/COFF/PDB.cpp:950
+
+  if (source->kind == TpiSource::PDB)
+    return; // No symbols in TypeServer PDBs
----------------
aganea wrote:
> I was wondering if we could pre-link some libraries to speed-up linking of rarely modified projects. We're building lots of external/third-party libraries compiled from source, because we want to enforce the same settings as the rest of the gamecode (for options like /MT or -flto=thin). However they are cached and very rarely compiled. But we'd still pay the cost to merge symbols and types at link-time.
> Maybe each library (or each group of libraries) could come with a /Zi-style .PDB which LLD would use instead of the library's .OBJs. If that ever happens, we'd need to merge symbols here as well.
True.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D79672/new/

https://reviews.llvm.org/D79672





More information about the llvm-commits mailing list