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

[Felipe de Azevedo Piovezan 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();
----------------
felipepiovezan wrote:

This is not really an area I'm very familiar with, but there are some things that I found odd about that PR.
For example, why do we need this?

```
  // Prime DebugInfoCache.
   // TODO: Currently, the only user is CoroSplitPass. Consider running
   // conditionally.
   AM.getResult<DebugInfoCacheAnalysis>(M);
```

> I was worried about unnecessary invalidations, but all CoroSplit passes will share the same analysis results as part of CGSCC pipeline.

Isn't this dangerous though? Each CoroSplit pass will modify the Module and its metadata, so the analysis need to be invalidated after every run of CoroSplit, which I believe is already being done (the pass ends with a `return PreservedAnalyses::none();`). In other words, we share cached results for all functions within the SCC, but not necessarily for all functions of the module. This implies we're doing a lot of unnecessary  work that will be invalidated.

Should this new analysis be lazy? I.e. only visit a CU when it is queried on it.

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