[clang] [llvm] [clang][deps] Add in-flight query caching to `DependencyScanningFilesystemSharedCache` (PR #199680)

[Artem Chikin via cfe-commits]

================
@@ -184,6 +184,101 @@ DependencyScanningFilesystemSharedCache::CacheShard::
   return *CachedEntry;
 }
 
+DependencyScanningFilesystemSharedCache::SlotAcquisitionResult
+DependencyScanningFilesystemSharedCache::CacheShard::acquireFilenameSlot(
+    StringRef Filename) {
+  assert(llvm::sys::path::is_absolute_gnu(Filename));
+  std::unique_lock<std::mutex> LockGuard(CacheLock);
+  // Cache hit.
+  if (auto It = CacheByFilename.find(Filename); It != CacheByFilename.end()) {
+    if (const auto *Entry = It->getValue().first)
+      return SlotAcquisitionResult{Entry, nullptr};
+  }
+
+  // Another worker is producing for this filename, wait for it.
+  if (auto It = InProgressByFilename.find(Filename);
+      It != InProgressByFilename.end()) {
+    std::shared_ptr<InProgressEntry> Pending = It->second;
+    Pending->CondVar.wait(LockGuard, [&] { return Pending->Done; });
----------------
artemcm wrote:

> but that must be causing a fair amount of spurious wake-ups when many threads concurrently use the same shard.

There shouldn't be any extra wake-ups. Each `InProgressEntry` owns its own `condition_variable`, so `notify_all` only wakes waiters on that one key; sharing the shard mutex doesn't spill wakeups across keys.

That said, there may still be contention on the shard lock with this mechanism so I took the suggestion and did the refactor: the shard `CacheLock` now guards only the maps and is released before the wait, which runs on a per-entry mutex/CV. 

I benchmarked this with a Swift dependency scan, and on a high-concurrency scan with a warm scanner-PCM filesystem cache, wall time dropped ~4% (5.69s → 5.46s), and run-to-run variance fell quite a bit as well. Cold-cache scans were flat with no regressions. Thanks!

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