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

[Daniel Berlin via llvm-commits]

On Fri, Oct 13, 2017 at 10:35 AM, Michael Zolotukhin <mzolotukhin at apple.com>
wrote:

>
> 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> 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?
>

So, this is actually why i went looking, because i had trouble believing it
was 4-10% slower (I've done a lot of testing of random cfgs :P)

I *believe* the motivation is that they want DT up to date *in-pass* so
they can use it do to better jump threading over loops.

*that* kind of change, IMHO, should be subject to our usual "how much
faster code does it make vs how much does it cost" tradeoff.


> 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?
>

This was *our* plan to remove the recalculates, but it does not appear to
have be what Sebastian/etc want for JT.


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