<div dir="ltr">BTW, here's a relevant stack trace:<div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><div>#0 llvm::ImutAVLFactory<llvm::ImutContainerInfo<clang::Stmt const*> >::add_internal (this=0x173ca90, V=0x1a0db10, T=0x20d5610) at llvm/include/llvm/ADT/ImmutableSet.h:551</div></div><div><div>#1 0x0000000000d76b25 in add_internal (T=0x244be90, V=<optimized out>, this=0x173ca90) at llvm/include/llvm/ADT/ImmutableSet.h:549</div></div><div><div>#2 add_internal (T=0x22ef820, V=<optimized out>, this=0x173ca90) at llvm/include/llvm/ADT/ImmutableSet.h:551</div></div><div><div>#3 add_internal (T=0x1f15790, V=<optimized out>, this=0x173ca90) at llvm/include/llvm/ADT/ImmutableSet.h:551</div></div><div><div>#4 llvm::ImutAVLFactory<llvm::ImutContainerInfo<clang::Stmt const*> >::add_internal (this=0x173ca90, V=<optimized out>, T=0x250a1b0)</div></div><div><div> at llvm/include/llvm/ADT/ImmutableSet.h:551</div></div><div><div>#5 0x0000000000d768e1 in add_internal (T=0x20eb1d0, V=<optimized out>, this=0x173ca90) at llvm/include/llvm/ADT/ImmutableSet.h:551</div></div><div><div>#6 add_internal (T=0x1f2c190, V=<optimized out>, this=0x173ca90) at llvm/include/llvm/ADT/ImmutableSet.h:551</div></div><div><div>#7 add_internal (T=0x24ca520, V=<optimized out>, this=0x173ca90) at llvm/include/llvm/ADT/ImmutableSet.h:551</div></div><div><div>#8 llvm::ImutAVLFactory<llvm::ImutContainerInfo<clang::Stmt const*> >::add_internal (this=0x173ca90, V=<optimized out>, T=<optimized out>)</div></div><div><div> at llvm/include/llvm/ADT/ImmutableSet.h:549</div></div><div><div>#9 0x0000000000d78bd2 in llvm::ImutAVLFactory<llvm::ImutContainerInfo<clang::Stmt const*> >::add (this=this@entry=0x173ca90, T=T@entry=0x2081090, V=<optimized out>)</div></div><div><div> at llvm/include/llvm/ADT/ImmutableSet.h:401</div></div><div><div>#10 0x0000000000d7cca1 in add (V=<optimized out>, this=<optimized out>) at llvm/include/llvm/ADT/ImmutableSet.h:1158</div></div><div><div>#11 mergeSets<llvm::ImmutableSetRef<clang::Stmt const*> > (B=..., A=...) at llvm/tools/clang/lib/Analysis/LiveVariables.cpp:81</div></div><div><div>#12 merge (valsB=<error reading variable: access outside bounds of object referenced via synthetic pointer>, </div></div><div><div> valsA=<error reading variable: access outside bounds of object referenced via synthetic pointer>, this=0x173ca70) at llvm/tools/clang/lib/Analysis/LiveVariables.cpp:103</div></div><div><div>#13 clang::LiveVariables::computeLiveness (AC=..., killAtAssign=killAtAssign@entry=true) at llvm/tools/clang/lib/Analysis/LiveVariables.cpp:489</div></div><div><div>#14 0x0000000000619099 in create (analysisContext=...) at llvm/tools/clang/include/clang/Analysis/Analyses/LiveVariables.h:99</div></div><div><div>#15 getAnalysis<clang::LiveVariables> (this=0x17db180) at llvm/tools/clang/include/clang/Analysis/AnalysisContext.h:200</div></div><div><div>#16 getAnalysis<clang::LiveVariables> (D=0x197c7d0, this=0x173ac30) at llvm/tools/clang/include/clang/StaticAnalyzer/Core/PathSensitive/AnalysisManager.h:119</div></div><div><div>#17 checkASTCodeBody (BR=..., mgr=..., D=0x197c7d0, this=<optimized out>) at llvm/tools/clang/lib/StaticAnalyzer/Checkers/DeadStoresChecker.cpp:437</div></div><div><div>#18 clang::ento::check::ASTCodeBody::_checkBody<(anonymous namespace)::DeadStoresChecker> (checker=0x173bae0, D=0x197c7d0, mgr=..., BR=...)</div></div><div><div> at llvm/tools/clang/include/clang/StaticAnalyzer/Core/Checker.h:56</div></div><div><div>#19 0x00000000008c42b0 in operator() (p3=..., p2=..., p1=0x197c7d0, this=<optimized out>) at llvm/tools/clang/include/clang/StaticAnalyzer/Core/CheckerManager.h:82</div></div><div><div>#20 clang::ento::CheckerManager::runCheckersOnASTBody (this=0x173a930, D=D@entry=0x197c7d0, mgr=..., BR=...) at llvm/tools/clang/lib/StaticAnalyzer/Core/CheckerManager.cpp:86</div></div><div><div>#21 0x000000000052e41d in (anonymous namespace)::AnalysisConsumer::HandleCode(clang::Decl *, (anonymous namespace)::AnalysisConsumer::AnalysisMode, enum clang::ento::ExprEngine::InliningModes, clang::ento::SetOfConstDecls *) (this=this@entry=0x16dffa0, D=D@entry=0x197c7d0, Mode=1, IMode=IMode@entry=clang::ento::ExprEngine::Inline_Minimal, VisitedCallees=VisitedCallees@entry=0x0)</div></div><div><div> at llvm/tools/clang/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp:623</div></div></blockquote><div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Sep 21, 2014 at 2:16 AM, Alexander Kornienko <span dir="ltr"><<a href="mailto:alexfh@google.com" target="_blank">alexfh@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">I'm attaching one of the files that regressed after r214064 and never got fixed (preprocessed ceval.c from Python 3.3).<div><div class="h5"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Sep 20, 2014 at 5:38 PM, Alexander Kornienko <span dir="ltr"><<a href="mailto:alexfh@google.com" target="_blank">alexfh@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><p dir="ltr">I actually still think, that I have some code that started taking large time to be analyzed after r214064 and didn't recover after r215650. But I didn't get to creating a reasonable repro for you. And the number of files left affected after r215650 is so small, that I didn't prioritize this high enough. I'll still try to provide a repro soon.</p><div><div>
<div class="gmail_quote">On 20 Sep 2014 17:10, "Artyom Skrobov" <<a href="mailto:Artyom.Skrobov@arm.com" target="_blank">Artyom.Skrobov@arm.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="EN-GB" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Anna, do you mean the performance had been acceptable after r214064, but degraded after r215650, which fixed the performance regression introduced in r214064?<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Do you have any specific example of code that takes longer to compile after r215650?<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Not hearing back from Alexander since August, I assumed the performance regression he observed after r215650 was not in fact related to that commit.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><div><div style="border-style:solid none none;border-top-color:rgb(181,196,223);border-top-width:1pt;padding:3pt 0cm 0cm"><p class="MsoNormal"><b><span lang="EN-US" style="font-size:10pt;font-family:Tahoma,sans-serif">From:</span></b><span lang="EN-US" style="font-size:10pt;font-family:Tahoma,sans-serif"> Anna Zaks [mailto:<a href="mailto:ganna@apple.com" target="_blank">ganna@apple.com</a>] <br><b>Sent:</b> 20 September 2014 01:19<br><b>To:</b> Artyom Skrobov<br><b>Cc:</b> <a href="mailto:cfe-commits@cs.uiuc.edu" target="_blank">cfe-commits@cs.uiuc.edu</a> Commits; Ted Kremenek; Jordan Rose; Alexander Kornienko<br><b>Subject:</b> Re: [PATCH] Inverse post-order traversal for LiveVariables analysis, to recover the performance after r214064<u></u><u></u></span></p></div></div><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Hi Artyom,<u></u><u></u></p><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Unfortunately, this commit (r215650) causes major performance regressions on our buildbots. In particular, building <span style="font-family:Menlo,serif">postgresql-9.1</span> times out.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Please, revert as soon as possible.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Thank you,<u></u><u></u></p></div><div><p class="MsoNormal">Anna.<u></u><u></u></p><div><blockquote style="margin-top:5pt;margin-bottom:5pt"><div><p class="MsoNormal">On Aug 20, 2014, at 3:13 AM, Alexander Kornienko <<a href="mailto:alexfh@google.com" target="_blank">alexfh@google.com</a>> wrote:<u></u><u></u></p></div><p class="MsoNormal"><u></u> <u></u></p><div><div><div><div><p class="MsoNormal">On Fri, Aug 15, 2014 at 10:38 AM, Artyom Skrobov <<a href="mailto:Artyom.Skrobov@arm.com" target="_blank">Artyom.Skrobov@arm.com</a>> wrote:<u></u><u></u></p><p class="MsoNormal">Many thanks -- committed as r215650<br><br>Alexander, can you confirm that the analyzer performance is now acceptable<br>for your use cases?<u></u><u></u></p><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Artyom, sorry for the long delay. These files now work fine, but I still see up to 8-10 hours analysis time on a couple of other files. I'm sure I didn't see this before your first patch, but I can't yet tell in which revision it was introduced. I'll post more details and a repro later today.<u></u><u></u></p></div><div><p class="MsoNormal"> <u></u><u></u></p></div><blockquote style="border-style:none none none solid;border-left-color:rgb(204,204,204);border-left-width:1pt;padding:0cm 0cm 0cm 6pt;margin-left:4.8pt;margin-right:0cm"><div><p class="MsoNormal" style="margin-bottom:12pt"><br><br>-----Original Message-----<br>From: Ted kremenek [mailto:<a href="mailto:kremenek@apple.com" target="_blank">kremenek@apple.com</a>]<br>Sent: 14 August 2014 16:36<br>To: Artyom Skrobov<br>Cc: Alexander Kornienko; <a href="mailto:cfe-commits@cs.uiuc.edu" target="_blank">cfe-commits@cs.uiuc.edu</a><br>Subject: Re: [PATCH] Inverse post-order traversal for LiveVariables<br>analysis, to recover the performance after r214064<u></u><u></u></p></div><div><div><p class="MsoNormal" style="margin-bottom:12pt">Looks great to me.<br><br>> On Aug 14, 2014, at 3:08 AM, Artyom Skrobov <<a href="mailto:Artyom.Skrobov@arm.com" target="_blank">Artyom.Skrobov@arm.com</a>><br>wrote:<br>><br>> Thank you Ted!<br>><br>> Attaching the updated patch for a final review.<br>><br>> Summary of changes:<br>><br>> * Comments updated to reflect the two possible CFG traversal orders<br>> * PostOrderCFGView::po_iterator taken out of the header file<br>> * Iteration order for PostOrderCFGView changed to "reverse inverse<br>> post-order", the one required for a backward analysis<br>> * ReversePostOrderCFGView created, with the same iteration order that<br>> PostOrderCFGView used to have, the one required for a forward analysis<br>> * The two previous consumers of PostOrderCFGView, ThreadSafetyCommon.h and<br>> Consumed.cpp, switched to use ReversePostOrderCFGView<br>> * DataflowWorklistBase renamed to DataflowWorklist, and the two<br>> specializations named BackwardDataflowWorklist and ForwardDataflowWorklist<br>><br>> I believe this naming scheme matches the accepted terminology best.<u></u><u></u></p></div></div></blockquote></div></div></div><p class="MsoNormal">_______________________________________________<br>cfe-commits mailing list<br><a href="mailto:cfe-commits@cs.uiuc.edu" target="_blank">cfe-commits@cs.uiuc.edu</a><br><a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits</a><u></u><u></u></p></div></blockquote></div><p class="MsoNormal"><u></u> </p></div></div></div></blockquote></div></div></div></blockquote></div>
</div></div></div></div>
</blockquote></div><br>
</div></div></div>