[llvm] r314435 - [JumpThreading] Preserve DT and LVI across the pass

Michael Zolotukhin via llvm-commits llvm-commits at lists.llvm.org
Fri Oct 13 10:35:05 PDT 2017


> On Oct 13, 2017, at 10:17 AM, Daniel Berlin <dberlin at dberlin.org> wrote:
> 
> 
> 
> On Fri, Oct 13, 2017 at 10:06 AM, Michael Zolotukhin <mzolotukhin at apple.com <mailto:mzolotukhin at apple.com>> wrote:
> Hi,
> 
> My apologies, “to be fixed” is indeed a bad wording.
> 
> I do agree that preserving DT is generally good. However, what we get from it *currently* is only slowdowns with some gains expected *in future* when other passes are taught to preserve DT as well. I believe that when all relevant passes preserve DT we’ll see compile-time improvements,
> 
> No you won't, at least, not if we preserve DT the way this has been implemented.
> Like I said, i believe you've misunderstood.
> If you make every pass preserve DT in this same way, it will just be slower.
Hmm, maybe I indeed misunderstood. What is the motivation for this change then? I thought we were going to replace one expensive DT->recalculate (which happens between passes when we don’t preserve DT) with several cheap incremental DT updates. Is this correct?

Michael
> 
> The preservation system is an inter-pass preservation system, not an intra-pass one.
> 
> That is, the recomputation is happening *once* between each pass.
> 
> Replacing the rebuilding that exists now would only require batching the updates and applying them once to DT at the end of jump threading (DT supports this already).  That will certainly be fast enough already.
> 
> The way this is being updated is not *once*, but *as we go*. 
> Not in the incremental sense, but in the quite literal sense of "for each cfg change that is made, the DT is updated" instead of "batch a bunch of CFG updates into a DT update".
> 
> *each* of those as-you go updates is saving a call to DT->recalculate that would otherwise exist.
> 
> So it's equivalent to adding a *ton* of DT->recalculate calls, and then making them faster by doing incremental updates.
> 
> There is no way to make this faster than a single recomputation of DT , because it's not equivalent to that, it's equivalent to adding DT->recalculate everywhere you DT->applyUpdates in this patch.
> 
> 
> 
>  
> that’s why I don’t want to lose this work and propose to put it under a flag (also to avoid bitrot). But now we’re just doing extra work for nothing - SimplifyCFG scheduled right after JT destroys DT and we have to recompute it anyway.
> 
> That's not why this is slow :)
> 
> It's slow because it's equivalent to adding 50 new DT recalculations, and then trying to make them faster by doing them incrementally.
> It would *already* be fast enough if instead it was "batch up all the updates, apply at end of jumpthreading", which would be equivalent to preserving DT the way the inter-pass system preserves it.
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20171013/5e917cb4/attachment.html>


More information about the llvm-commits mailing list