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

[Brian M. Rzycki via llvm-commits]

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

Daniel, you are correct in this assumption. Dominance is the first step in
enhancing the kinds of analysis and extend the number of Jumpthreading
opportunities. Analysis of loops is part of this work.

*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 have not started the work on actual code optimizations simply because I
could not intelligently make the analysis decisions needed. Rather than
create a huge change to JT (or another pass) Sebastian and I decided to
incrementally update JT with the features we needed to get us to the end
goal.

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

I'm a bit confused by this statement: that's what the patch is doing.
There's only one corner-case where a recalculate occurs. The rest of the
time it's incremental updates.  There may still be opportunities to batch
updates but I honestly have no idea if it will be more efficient. If this
is a concern I can talk to Sebastian when he returns to work on Monday
about re-working the patch for batching.  Or we could talk about it in
person at the LLVM conference next week. :)


On Fri, Oct 13, 2017 at 12:39 PM, Daniel Berlin <dberlin at dberlin.org> wrote:

>
>
> 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/67ebe8a8/attachment.html>