Any news here? This keeps biting us. Maybe you can apply this patch first and work on a better solution after that?
On Tue, Aug 5, 2014 at 6:23 PM, Artyom Skrobov <[email protected]> wrote: > So, the simplest way to restore the original behaviour seems to be > > > > Index: lib/Analysis/LiveVariables.cpp > > =================================================================== > > --- lib/Analysis/LiveVariables.cpp (revision 214183) > > +++ lib/Analysis/LiveVariables.cpp (working copy) > > @@ -451,6 +451,7 @@ > > // Construct the dataflow worklist. Enqueue the exit block as the > > // start of the analysis. > > DataflowWorklist worklist(*cfg, AC); > > + worklist.quick_hack(); > > llvm::BitVector everAnalyzedBlock(cfg->getNumBlockIDs()); > > // FIXME: we should enqueue using post order. > > Index: include/clang/Analysis/Analyses/DataflowWorklist.h > > =================================================================== > > --- include/clang/Analysis/Analyses/DataflowWorklist.h (revision > 214183) > > +++ include/clang/Analysis/Analyses/DataflowWorklist.h (working copy) > > @@ -53,6 +53,7 @@ > > const CFGBlock *dequeue(); > > void sortWorklist(); > > + void quick_hack() { enqueuedBlocks.reset(); PO_I = PO_E; } > > }; > > } // end clang namespace > > > > This has the effect of disabling the fallback post-order iteration. > > > > The reason for the performance regression, however, is related to the > iteration order over the CFG: UninitializedValues expects to use the > default (i.e. reverse) PostOrderCFGView iteration, whereas LiveVariables > expects the opposite order, corresponding to using > llvm::GraphTraits<llvm::Inverse<const CFG*> > > as the last parameter in > typedef po_iterator. > > > > I’m currently thinking of a proper solution which would allow using > PostOrderCFGView for iteration in either direction. > > > > > > > > *From:* Alexander Kornienko [mailto:[email protected]] > *Sent:* 05 August 2014 12:30 > > *To:* Artyom Skrobov > *Cc:* [email protected] Commits > *Subject:* Re: r214064 - Factoring DataflowWorklist out of LiveVariables > and UninitializedValues analyses > > > > On another file from the same project the difference in my setup is 2 > minutes before the patch vs. 50+ hours (I terminated the analyzer before it > finished) after the patch. So it's a rather bad performance regression. > > > > On Tue, Aug 5, 2014 at 10:17 AM, Artyom Skrobov <[email protected]> > wrote: > > Indeed, for the other version of options.c, the analysis (on my machine) > takes 3 sec before the patch, and 6 min after the patch. > > It doesn’t hang indefinitely though, and the output is the same in both > cases; so what we have is a performance regression. > > > > I’m now trying a fix. > > > > > > *From:* Alexander Kornienko [mailto:[email protected]] > *Sent:* 04 August 2014 19:26 > *To:* Artyom Skrobov > > > *Subject:* Re: r214064 - Factoring DataflowWorklist out of LiveVariables > and UninitializedValues analyses > > > > On Mon, Aug 4, 2014 at 4:36 PM, Artyom Skrobov <[email protected]> > wrote: > > Are you sure this issue has anything to do with my patch? > > I’ve just run “clang -cc1 -analyze -analyzer-checker=deadcode.DeadStores > options.i” using a build of Clang pre-dating my patch by a couple of weeks; > and the analysis hangs nevertheless. > > > > You're right. This specific file causes hangs regardless of your patch. > Sorry for not verifying this. > > > > However, I've got another version of this file, which only makes analyzer > hang with your patch. Please try it. > > >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
