[llvm] [Analysis] Add DebugInfoCache analysis (PR #118629)

[Artem Pianykh via llvm-commits]

================
@@ -0,0 +1,47 @@
+//===- llvm/Analysis/DebugInfoCache.cpp - debug info cache ----------------===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+//
+// This file contains an analysis that builds a cache of debug info for each
+// DICompileUnit in a module.
+//
+//===----------------------------------------------------------------------===//
+
+#include "llvm/Analysis/DebugInfoCache.h"
+#include "llvm/IR/Module.h"
+
+using namespace llvm;
+
+namespace {
+DebugInfoFinder processCompileUnit(DICompileUnit *CU) {
+  DebugInfoFinder DIFinder;
+  DIFinder.processCompileUnit(CU);
+
+  return DIFinder;
+}
+} // namespace
+
+DebugInfoCache::DebugInfoCache(const Module &M) {
+  for (const auto CU : M.debug_compile_units()) {
+    auto DIFinder = processCompileUnit(CU);
+    Result[CU] = std::move(DIFinder);
+  }
+}
+
+bool DebugInfoCache::invalidate(Module &M, const PreservedAnalyses &PA,
+                                ModuleAnalysisManager::Invalidator &) {
+  // Check whether the analysis has been explicitly invalidated. Otherwise, it's
+  // stateless and remains preserved.
+  auto PAC = PA.getChecker<DebugInfoCacheAnalysis>();
+  return !PAC.preservedWhenStateless();
----------------
artempyanykh wrote:

@felipepiovezan I ran validation on a large chunk of our internal codebase with a patched version of LLVM that had an extra set of checks to compare cached DIFinder with the one built from scratch ([roughly this diff](https://gist.github.com/artempyanykh/49382b32b6427f6421219902480fdb6f)). No mismatches found.

The line of reasoning here is that in the context of CoroSplit pass this analysis result (cached DIFinder) is not invalidated since:
* it doesn't add/remove debug info attached *specifically* to Compile Unit (this is what gets cached by running `DebugInfoFinder::processCompileUnit`; note that these are only things reachable directly from a CU, rather than everything inside the CU),
* the contents of the cachedDIFinder get identity mapped and hence are unchanged by construction.

Seems safe to have this analysis on specifically for CoroSplit at least.

----

With that said, I had another idea. I refactored the code a bit more and it seems that whatever is going on now with the DIFinder and collecting IdentityMD metadata set for identity mapping basically **reduces to a predicate check on metadata** to

> identity map compile units, types, other subprograms, and lexical blocks of other subprograms.

I have a stack that implements this. Most of the stack is refactoring to prepare for the change and then cleaning up after the change. The two important PRs are:
* https://github.com/llvm/llvm-project/pull/129147 (set.contains replaced with `predicate(metadata)` check in ValueMapper interface).
* https://github.com/llvm/llvm-project/pull/129148 (a generic change to CloneFunction.cpp; a predicate based on set.contains with the set extracted via DIFinder is replaced with another predicate that just checks metadata kind). **This is the only non-trivial transformation in the whole stack**

All existing tests pass incl. cloning and coroutine tests, which is a good indication that #129148 is functionally equivalent to the current version. @felipepiovezan could you have a look at #129148? If looks good, I'd prefer this new version to the DebugInfoCacheAnalysis.

https://github.com/llvm/llvm-project/pull/118629