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

[Daniel Berlin via llvm-commits]

On Fri, Oct 13, 2017 at 10:06 AM, Michael Zolotukhin <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.

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/73d36529/attachment.html>