<div dir="ltr"><div>#10 0x000055680f8d7466 (anonymous namespace)::DAGCombiner::SimplifyBinOpWithSameOpcodeHands(llvm::SDNode*)</div><div><br></div><div>Thanks! That's a good lead. I'm looking at that code now, and it doesn't appear to check the number of uses before doing transforms. That means it can increase the instruction count at each invocation. Let me try some experiments in there.<br></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Dec 5, 2018 at 7:51 PM David Jones <<a href="mailto:dlj@google.com">dlj@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Wed, Dec 5, 2018 at 6:34 PM Friedman, Eli <<a href="mailto:efriedma@codeaurora.org" target="_blank">efriedma@codeaurora.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<div class="m_2049016642620054492gmail-m_2926150902519051473moz-cite-prefix">On 12/5/2018 5:47 PM, David Jones
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr"><br>
<div class="gmail_quote">
<div dir="ltr">On Wed, Dec 5, 2018 at 5:40 PM Sanjay Patel
<<a href="mailto:spatel@rotateright.com" class="m_2049016642620054492gmail-cremed m_2049016642620054492gmail-cremed m_2049016642620054492gmail-cremed m_2049016642620054492cremed" target="_blank">spatel@rotateright.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div dir="auto">Hi David,</div>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">Thanks for reporting the problem. I don’t
have any guesses as to how this could cause OOM. Cc’ing
some people that might.</div>
</blockquote>
<div><br>
</div>
<div>+a few more, thanks! :-)</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="auto">If the problem is only showing up on PPC,
a quick hack would be to add a TLI hook and disable the
transform for PPC. I’d prefer that to a full revert
(especially since I’ve already enhanced this code to
handle some vectors, and another enhancement is in
progress)...unless we have a test case that shows it’s
not a PPC-specific bug?</div>
<div dir="auto"><br>
</div>
</blockquote>
<div><br>
</div>
<div>Agreed on avoiding a revert... this looks like a pretty
hard-fought change, based on <a href="https://bugs.llvm.org/show_bug.cgi?id=32023" class="m_2049016642620054492gmail-cremed m_2049016642620054492gmail-cremed m_2049016642620054492gmail-cremed m_2049016642620054492cremed" target="_blank">https://bugs.llvm.org/show_bug.cgi?id=32023</a>.</div>
<div><br>
</div>
<div>I do believe this is PPC-specific (although, as is
often the case, your change may simply be tickling a bug
somewhere else).</div>
</div>
</div>
</div>
</blockquote>
<p>If it's PPC-specific, my first guess here would be there's some
PowerPC-specific target combine that's trying to combine the
opposite way, or something like that. Assuming that's the case,
it probably runs out of memory pretty quickly, so it should be
fast to bisect if you restrict the memory usage with ulimit.<br></p></div></blockquote><div><br></div><div>So I did try something like this... instead of just ulimit, I patched my allocator to crash when it sees a sufficiently large allocation (so I can see the large allocation itself, not just a random allocation when close to the limit).</div><div><br></div><div>Here's a stacktrace I got (slightly edited for clarity):</div><div><br></div><div><div>1.<span style="white-space:pre-wrap"> </span><eof> parser at end of file</div><div>2.<span style="white-space:pre-wrap"> </span>Code generation</div><div>3.<span style="white-space:pre-wrap"> </span>Running pass 'Function Pass Manager' on module 'FrontendAction-9a7810.cpp'.</div><div>4.<span style="white-space:pre-wrap"> </span>Running pass 'PowerPC DAG->DAG Pattern Instruction Selection' on function '@_ZN5clang14FrontendAction15BeginSourceFileERNS_16CompilerInstanceERKNS_17FrontendInputFileE'</div><div>#0 0x000055681055d388 llvm::sys::RunSignalHandlers()</div><div>#1 0x000055681055f486 SignalHandler(int)</div><div>#2 0x00007f88bd9f89a0 __restore_rt</div><div>#3 0x00007f88bd77a602 __GI_raise</div><div>#4 0x00007f88bd77c320 __GI_abort</div><div>#5 0x00005568105e2a70 tcmalloc::Logger::Add(tcmalloc::LogItem const&)</div><div>#6 0x00005568105d5838 (anonymous namespace)::do_malloc_pages(unsigned long, unsigned long)</div><div>#7 0x000055681068a56d realloc</div><div>#8 0x000055681055c789 llvm::SmallVectorBase::grow_pod(void*, unsigned long, unsigned long)</div><div>#9 0x000055680f895119 (anonymous namespace)::DAGCombiner::AddToWorklist(llvm::SDNode*)</div><div>#10 0x000055680f8d7466 (anonymous namespace)::DAGCombiner::SimplifyBinOpWithSameOpcodeHands(llvm::SDNode*)</div><div>#11 0x000055680f8a1791 (anonymous namespace)::DAGCombiner::visitAND(llvm::SDNode*)</div><div>#12 0x000055680f89729b (anonymous namespace)::DAGCombiner::combine(llvm::SDNode*)</div><div>#13 0x000055680f8960cf llvm::SelectionDAG::Combine(llvm::CombineLevel, llvm::AAResults*, llvm::CodeGenOpt::Level)</div><div>#14 0x000055680f78cdbc llvm::SelectionDAGISel::CodeGenAndEmitDAG()</div><div>#15 0x000055680f78bbde llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&)</div><div>#16 0x000055680f788c56 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&)</div><div>#17 0x000055680f418574 (anonymous namespace)::PPCDAGToDAGISel::runOnMachineFunction(llvm::MachineFunction&)</div><div>#18 0x000055680fa0955b llvm::MachineFunctionPass::runOnFunction(llvm::Function&)</div><div>#19 0x0000556810478c6c llvm::FPPassManager::runOnFunction(llvm::Function&)</div><div>#20 0x0000556810478f23 llvm::FPPassManager::runOnModule(llvm::Module&)</div><div>#21 0x00005568104793f5 llvm::legacy::PassManagerImpl::run(llvm::Module&)</div><div>#22 0x000055680da6c9ff clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout const&, llvm::Module*, clang::BackendAction, std::unique_ptr<llvm::raw_pwrite_stream, std::default_delete<llvm::raw_pwrite_stream> >)</div><div>#23 0x000055680da43542 clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&)</div><div>#24 0x000055680e47c7b3 clang::ParseAST(clang::Sema&, bool, bool)</div><div>#25 0x000055680e2bc0fa clang::FrontendAction::Execute()</div><div>#26 0x000055680e142428 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)</div><div>#27 0x000055680d80b562 clang::ExecuteCompilerInvocation(clang::CompilerInstance*)</div><div>#28 0x000055680d7fab05 cc1_main(llvm::ArrayRef<char const*>, char const*, void*)</div><div>#29 0x000055680d8088ea main</div><div>#30 0x00007f88bd766bbd __libc_start_main</div><div>#31 0x000055680d7fa469 _start</div></div><div><br></div><div><br></div><div>(I've been poking at this in a few other ways... the stacks vary somewhat, but they all seem to point to an ever-growing work list in DAGCombiner, inside of PPCDAGToDAGISel -- so #13-#31 seem to be the common parts of the stacks.)</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF">
</div>
</blockquote></div></div></div></div></div>
</blockquote></div>