[llvm] [BOLT] Gadget scanner: refactor analysis of RET instructions (PR #131897)

[Anatoly Trosinenko via llvm-commits]

================
@@ -438,27 +469,19 @@ void Analysis::runOnFunction(BinaryFunction &BF,
     BF.dump();
   });
 
-  if (BF.hasCFG()) {
-    PacRetAnalysis PRA(BF, AllocatorId, {});
-    FunctionAnalysisResult FAR = computeDfState(PRA, BF, AllocatorId);
-    if (!FAR.RegistersAffected.empty()) {
-      // Redo the analysis, but now also track which instructions last wrote
-      // to any of the registers in RetRegsWithGadgets, so that better
-      // diagnostics can be produced.
-      std::vector<MCPhysReg> RegsToTrack;
-      for (MCPhysReg R : FAR.RegistersAffected)
-        RegsToTrack.push_back(R);
-      PacRetAnalysis PRWIA(BF, AllocatorId, RegsToTrack);
-      FAR = computeDfState(PRWIA, BF, AllocatorId);
-    }
+  if (!BF.hasCFG())
+    return;
 
-    // `runOnFunction` is typically getting called from multiple threads in
-    // parallel. Therefore, use a lock to avoid data races when storing the
-    // result of the analysis in the `AnalysisResults` map.
-    {
-      std::lock_guard<std::mutex> Lock(AnalysisResultsMutex);
-      AnalysisResults[&BF] = FAR;
-    }
+  FunctionAnalysisResult FAR = computeDfState(BF, AllocatorId);
----------------
atrosinenko wrote:

I will try to came up with a better code structure around this function (and name the resulting functions appropriately) - after all, it is this PR that moves almost everything from `runOnFunction` to `computeDfState` (which is basically "scan the function" now), but deleting `computeDfState` and simply moving everything to `runOnFunction` instead looks like even worse solution.

With the changes made by this PR, it should be possible to replace `computeDfState` with something like "find gadgets" and "augment reports with context information" parts, I think.

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