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

[Brian M. Rzycki via llvm-commits]

>
> 1. Be able to update the postdominatortree if it's around
> 2. Be able to update the dominatortree if it's around

Understood, it makes sense this way. I have a few follow-up questions about
this interface:

   1. Should this interface ignore duplicate edge updates? I was thinking
   of keeping the requests as a set internally and converting to a Vector at
   update time. Either that or adding an applyUpdates() method to DT that
   takes a set instead of an arrayref.
   2. How should the corner-cases we've discussed in the past be handled?
   For example, the case where the root node is deleted in the DT or the
   problems we saw with PDT and the hidden "exit" node failures.  Should this
   new interface fix these up or should that code be done in the DT and PDT
   classes?
   3. From the thread it's still a bit unclear to me if the flush() event
   is detected or is explicitly called (or possibly both?)

I definitely would like to sit down with you two and discuss this work. If
you have the time during the conference I'd like to whiteboard some of the
ideas for a clear direction of these changes. :)

Thanks,
-Brian

On Mon, Oct 16, 2017 at 10:55 AM, Daniel Berlin <dberlin at dberlin.org> wrote:

>
>
> On Mon, Oct 16, 2017 at 7:48 AM, Brian M. Rzycki <brzycki at gmail.com>
> wrote:
>
>> Sounds good. I want to make sure you feel like you can make forward
>>> progress as quickly as possible (I know starting to fix all this has been a
>>> drag), so if you want to do it earlier, let me know and we'll figure
>>> something out :)
>>
>> Thanks Daniel for all the help. If it needs more work to be done right
>> then I'll get on it. I want to make sure we get it right. :)
>>
>>  I was thinking about this over the weekend and I was thinking of a new
>> class named DeferredDeviceTree or DeviceTreeDeferred.
>>
>
> (I assume you meant dominator)
>
> So let me try to give you my ideal design goals:
> 1. Be able to update the postdominatortree if it's around
> 2. Be able to update the dominatortree if it's around
> (The same edge updates will work for both)
> 3. Only have to add one argument to existing functions to do #1 and #2
> 4. Only have one updater object/class that things have to use to do #1 and
> #2
>
> The easiest option i see to do this:
> Make an updater object that can take a DT and a PDT pointer, and
> internally apply the same edge updates to both. Modify everywhere to use it.
>
> For example, you don't want everywhere to have to do
>
> DT->insertedge(a, b)
> PDT->insertedge(a, b)
>
> The only thing this invites is getting one of the lines wrong by accident
> (or forgetting it).
>
> Would it be okay if we had to?
> Sure, but i don't (right now) see the advantage over an updater object.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20171016/be5416f2/attachment.html>