<div>I've tried to dump the IR out at the end of my pipeline and invoking opt separately with the following output:</div><div><br></div><div>```</div><div>opt -verify O3bug.ll</div><div>```</div><div>is fine from LLVM12 stock opt.</div><div><br></div><div>Yet running ``opt -O3 O3bug.ll`` yields the exact same crash.</div><div><br></div><div>Is there any infrastructure to help me reduce the IR for bug reporting? The full IR contains some sensitive information that we'd avoid posting publicly.</div><div>Thanks a lot</div><div><includetail><div> </div><div> </div><div style="font:Verdana normal 14px;color:#000;"><div style="FONT-SIZE: 12px;FONT-FAMILY: Arial Narrow;padding:2px 0 2px 0;">------------------ Original ------------------</div><div style="FONT-SIZE: 12px;background:#efefef;padding:8px;"><div id="menu_sender"><b>From: </b> "llvm-dev"<llvm-dev@lists.llvm.org>;</div><div><b>Date: </b> Thu, Jul 22, 2021 10:24 AM</div><div><b>To: </b> "Florian Hahn"<florian_hahn@apple.com>; "llvm-dev"<llvm-dev@lists.llvm.org>; <wbr></div><div></div><div><b>Subject: </b> Re: [llvm-dev] Unexpected crash in IndVarSimplify after injecting custom pass</div></div><div> </div><div style="position:relative;"><div id="tmpcontent_res"></div><div><font>Thanks Florian.</font></div><div><font>To confirm, just leaving getAnalysisUsage unimplemented in my outside ModulePass is the correct way to instruct the remaining pipeline that "I've transformed Input enough that all previous analysis are no longer valid", right?</font></div><div><font><br></font></div><div><font>Zhang</font></div><div><div> </div><div> </div><div style="font:Verdana normal 14px;color:#000;"><div style="FONT-SIZE: 12px;FONT-FAMILY: Arial Narrow;padding:2px 0 2px 0;">------------------ Original ------------------</div><div style="FONT-SIZE: 12px;background:#efefef;padding:8px;"><div id="menu_sender"><b>From: </b> "Florian Hahn"<florian_hahn@apple.com>;</div><div><b>Date: </b> Wed, Jul 21, 2021 05:16 PM</div><div><b>To: </b> "Zhang"<admin@mayuyu.io>; "llvm-dev"<llvm-dev@lists.llvm.org>; <wbr></div><div></div><div><b>Subject: </b> Re: [llvm-dev] Unexpected crash in IndVarSimplify after injecting custom pass</div></div><div> </div><div style="position:relative;"><div id="tmpcontent_res"></div>Hi,<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 21 Jul 2021, at 10:11, Zhang via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><font class="">Hi:</font></div><div class=""><font class="">Here in our downstream project we use a ModulePass to schedule our TransformPasses through creating and executing Module/FunctionPassManagers internally.</font></div><div class=""><font class="">This "wrapper" pass is registered at ExtensionPoint EP_ModuleOptimizerEarly.</font></div><div class=""><font class=""><br class=""></font></div><div class=""><font class="">However, when certain passes in our Pipeline are disabled, LLVM optimization process crashes later in the pipeline with:</font></div><div class=""><font class=""><br class=""></font></div><div class=""><font class="">```</font></div><div class=""><div class="">Assertion failed: (L->getLoopPreheader() && "Can't expand add recurrences without a loop preheader!"), function getAddRecExprPHILiterally, file LLVM/llvm/lib/Transforms/Utils/ScalarEvolutionExpander.cpp, line 1275</div><div class="">1.<span class="Apple-tab-span" style="white-space:pre"> </span><eof> parser at end of file</div><div class="">2.<span class="Apple-tab-span" style="white-space:pre">       </span>Per-module optimization passes</div><div class="">3.<span class="Apple-tab-span" style="white-space:pre">  </span>Running pass 'CallGraph Pass Manager' on module 'src.cpp'.</div><div class="">4.<span class="Apple-tab-span" style="white-space:pre">      </span>Running pass 'Loop Pass Manager' on function '@_ZNK8XXXX'</div><div class="">5.<span class="Apple-tab-span" style="white-space:pre">       </span>Running pass 'Induction Variable Simplification' on basic block '%for.body110'</div><div class="">0  clang++                  0x0000000103df5535 llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 37</div><div class="">1  clang++                  0x0000000103df4765 llvm::sys::RunSignalHandlers() + 85</div><div class="">2  clang++                  0x0000000103df4cc0 llvm::sys::CleanupOnSignal(unsigned long) + 208</div><div class="">3  clang++                  0x0000000103d45f2a (anonymous namespace)::CrashRecoveryContextImpl::HandleCrash(int, unsigned long) + 106</div><div class="">4  clang++                  0x0000000103d460b7 CrashRecoverySignalHandler(int) + 135</div><div class="">5  libsystem_platform.dylib 0x00007fff2055ed7d _sigtramp + 29</div><div class="">6  libdyld.dylib            0x00007fff20534473 dyldGlobalLockRelease() + 0</div><div class="">7  libsystem_c.dylib        0x00007fff2046d720 abort + 120</div><div class="">8  libsystem_c.dylib        0x00007fff2046c9d6 err + 0</div><div class="">9  clang++                  0x0000000106c11a83 llvm::SCEVExpander::getAddRecExprPHILiterally(llvm::SCEVAddRecExpr const*, llvm::Loop const*, llvm::Type*, llvm::Type*, llvm::Type*&, bool&) (.cold.1) + 35</div><div class="">10 clang++                  0x0000000103eb9643 llvm::SCEVExpander::getAddRecExprPHILiterally(llvm::SCEVAddRecExpr const*, llvm::Loop const*, llvm::Type*, llvm::Type*, llvm::Type*&, bool&) + 4259</div><div class="">11 clang++                  0x0000000103eb9bda llvm::SCEVExpander::expandAddRecExprLiterally(llvm::SCEVAddRecExpr const*) + 1066</div><div class="">12 clang++                  0x0000000103eb5f23 llvm::SCEVExpander::expand(llvm::SCEV const*) + 1027</div><div class="">13 clang++                  0x0000000103eb5aac llvm::SCEVExpander::expandCodeFor(llvm::SCEV const*, llvm::Type*) + 28</div><div class="">14 clang++                  0x0000000103ebbc31 llvm::SCEVVisitor<llvm::SCEVExpander, llvm::Value*>::visit(llvm::SCEV const*) + 193</div><div class="">15 clang++                  0x0000000103eb5f23 llvm::SCEVExpander::expand(llvm::SCEV const*) + 1027</div><div class="">16 clang++                  0x0000000103eb5aac llvm::SCEVExpander::expandCodeFor(llvm::SCEV const*, llvm::Type*) + 28</div><div class="">17 clang++                  0x0000000103eb8c49 llvm::SCEVExpander::getAddRecExprPHILiterally(llvm::SCEVAddRecExpr const*, llvm::Loop const*, llvm::Type*, llvm::Type*, llvm::Type*&, bool&) + 1705</div><div class="">18 clang++                  0x0000000103eb9bda llvm::SCEVExpander::expandAddRecExprLiterally(llvm::SCEVAddRecExpr const*) + 1066</div><div class="">19 clang++                  0x0000000103eb5f23 llvm::SCEVExpander::expand(llvm::SCEV const*) + 1027</div><div class="">20 clang++                  0x0000000103eb5aac llvm::SCEVExpander::expandCodeFor(llvm::SCEV const*, llvm::Type*) + 28</div><div class="">21 clang++                  0x0000000103eb9794 llvm::SCEVExpander::expandCodeFor(llvm::SCEV const*, llvm::Type*, llvm::Instruction*) + 148</div><div class="">22 clang++                  0x0000000103b3969a (anonymous namespace)::IndVarSimplify::run(llvm::Loop*) + 8522</div><div class="">23 clang++                  0x0000000103b463c7 (anonymous namespace)::IndVarSimplifyLegacyPass::runOnLoop(llvm::Loop*, llvm::LPPassManager&) + 951</div><div class="">24 clang++                  0x00000001030ee209 llvm::LPPassManager::runOnFunction(llvm::Function&) + 1513</div><div class="">25 clang++                  0x00000001036afe41 llvm::FPPassManager::runOnFunction(llvm::Function&) + 1073</div><div class="">26 clang++                  0x0000000102ff4534 (anonymous namespace)::CGPassManager::runOnModule(llvm::Module&) + 1540</div><div class="">27 clang++                  0x00000001036b049f llvm::legacy::PassManagerImpl::run(llvm::Module&) + 1103</div><div class="">28 clang++                  0x000000010407b653 clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout const&, llvm::Module*, clang::BackendAction, std::__1::unique_ptr<llvm::raw_pwrite_stream, std::__1::default_delete<llvm::raw_pwrite_stream> >) + 15075</div><div class="">29 clang++                  0x00000001043456fb clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) + 1131</div><div class="">30 clang++                  0x0000000105438483 clang::ParseAST(clang::Sema&, bool, bool) + 643</div><div class="">31 clang++                  0x0000000104612d04 clang::FrontendAction::Execute() + 84</div><div class="">32 clang++                  0x00000001045b9f13 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 2179</div><div class="">33 clang++                  0x00000001046878fb clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1435</div><div class="">34 clang++                  0x00000001025db371 cc1_main(llvm::ArrayRef<char const*>, char const*, void*) + 2081</div><div class=""><br class=""></div></div><div class=""><font class="">```</font></div><div class=""><font class=""><br class=""></font></div><div class=""><font class="">I added createVerifierPass() at the end of our "WrapperPass" and the transformed IR passed the verification. I also didn't overload getAnalysisUsage, which, if my understanding is correct, invalidates all previous analysis including Loops Identified.</font></div></div></blockquote><br class=""></div><div>If IndVarSimplify crashes on valid IR, this is likely a bug. To confirm this, you can extract the IR before IndVarSimplify and check if running IndVarSimplify via opt on the extracted IR also crashes. </div><div><br class=""></div><div>If that’s the case, please file a bug report online <a href="https://bugs.llvm.org" class="">https://bugs.llvm.org</a> including the IR that causes IndVarSimplify to crash.</div><div><br class=""></div><div>Cheers,</div><div>Florian</div><br class="">
</div></div></div></div></div><!--<![endif]--></includetail></div>