Unable to find requested analysis info (Interesting Assertion Failture for Specific Target Source Code)

Dear all,

Hi! I encounter an interesting assertion failure when implementing my Pass, which is defined with the member functions shown below:

======================My Pass======================================

bool MYPass::runOnModule(Module &M)

{

for (auto &F : M)

{

SE = &getAnalysis(F).getSE();

}

}

return false;

}

void MYPass::getAnalysisUsage(AnalysisUsage &AU) const

{

AU.setPreservesAll();

AU.addRequired();

AU.addRequired();

AU.addRequired();

AU.addRequired();

AU.addRequired();

}

Dear all,

Hi! I encounter an interesting assertion failure: (sorry for re-sending the email because I need to add the details of the assertion)

/usr/local/include/llvm/PassAnalysisSupport.h:262: AnalysisType& llvm::Pass::getAnalysisID(llvm::AnalysisID, llvm::Function&) [with AnalysisType = llvm::ScalarEvolutionWrapperPass; llvm::AnalysisID = const void*]: Assertion `ResultPass && “Unable to find requested analysis info”’ failed

when implementing my Pass, which is defined with the member functions shown below:

======================My Pass======================================

bool MYPass::runOnModule(Module &M)

{

for (auto &F : M)

{

SE = &getAnalysis(F).getSE();

}

}

return false;

}

void MYPass::getAnalysisUsage(AnalysisUsage &AU) const

{

AU.setPreservesAll();

AU.addRequired();

AU.addRequired();

AU.addRequired();

AU.addRequired();

AU.addRequired();

}

See this:

http://lists.llvm.org/pipermail/llvm-dev/2019-March/131346.html

I have also had trouble with function-level analysis passes used by a
ModulePass. It seems like the legacy pass manager simply doesn't
support it. It works fine with the new pass manager.

What's scary is that the code compiles just fine but it fails at runtime
(for some codes, as you've observed) because the legacy pass manager
deletes each function analysis pass sometime after getAnalysis is run.

The on-the-fly pass manager systems seems fundamentally broken to me,
though I haven't got any responses on that post that either confirm or
deny that.

                     -David

Tingyuan LIANG via llvm-dev <llvm-dev@lists.llvm.org> writes: