[llvm-branch-commits] [llvm] ExpandFp: Require RuntimeLibcallsInfo analysis (PR #165197)

Frederik Harwath via llvm-branch-commits llvm-branch-commits at lists.llvm.org
Tue Oct 28 07:08:27 PDT 2025


================
@@ -1126,13 +1130,23 @@ PreservedAnalyses ExpandFpPass::run(Function &F, FunctionAnalysisManager &FAM) {
   AssumptionCache *AC = nullptr;
   if (OptLevel != CodeGenOptLevel::None)
     AC = &FAM.getResult<AssumptionAnalysis>(F);
+
+  auto &MAMProxy = FAM.getResult<ModuleAnalysisManagerFunctionProxy>(F);
+  const RTLIB::RuntimeLibcallsInfo *Libcalls =
+      MAMProxy.getCachedResult<RuntimeLibraryAnalysis>(*F.getParent());
----------------
frederik-h wrote:

@arsenm In the PR description, you wrote:

>  Not sure I'm doing the new pass manager handling correctly. I do
> not like needing to manually check if the cached module pass is
> available and manually erroring in every pass.

I am not super familiar with the details of this, but I had a look at the implementation and the documentation. The documentation on `ModuleAnalysisManagerFunctionProxy` aka `OuterAnalysisManagerProxy<ModuleAnalysisManager, Function>`  in `include/llvm/IR/PassManager.h` states that:

> This proxy only exposes the const interface of the outer analysis manager,
> to indicate that you cannot cause an outer analysis to run from within an
> inner pass.  Instead, you must rely on the getCachedResult API.
> This is due to keeping potential future concurrency in mind. 

Hence it seems to me that you cannot/should not request the computation of the analysis information from here and you need to do it in this way.

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


More information about the llvm-branch-commits mailing list