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

Daniel Berlin via llvm-commits llvm-commits at lists.llvm.org
Mon Oct 16 08:38:37 PDT 2017


On Mon, Oct 16, 2017 at 8:31 AM, Jakub (Kuba) Kuderski <
kubakuderski at gmail.com> wrote:

> Hi Brian,
>
>
>>  I was thinking about this over the weekend and I was thinking of a new
>> class named DeferredDeviceTree or DeviceTreeDeferred. It would have the
>> following methods:
>> deleteEdge()
>> insertEdge()
>> appyUpdates(Updates)
>> sync()
>>
>
> s/Device/Dominator? :P
>
> My first observation would be that we don't really need deleteEdge and
> insertEdge, as the applyUpdates can now perform a non-batching update when
> there is only one qnqueued -- I think that applyUpdates is enough, end with
> initializer list passed is not that verbose (Sth.applyUpdates({DT::Insert,
> BB_A, BB_B}). Instead, it would be nice to have some automatic way of
> handling current IR API like replaceAllUsesWith that is cumbersome with the
> current CFG-level update logic.
>
> Then, I think that it might be also possible to deffer updates until
> someone calls DT.dominates(...) or similar function that need DT to be
> updated,
>

You'd have to do it when getNode, dominates, children, etc, pretty much
every method.



> so maybe it would make sense to make the interface lazy all the way and
> not expose the synchronization at all?
>

If you think we can pull it off, ...


> Or only provide synchronization for debugging.
> The problem I see with this approach is that it would not immediately
> obvious how to be smart enough not to store invalid pointers to already
> deleted basic blocks.
>

I don't see why a combination of two things wouldn't work:
1. WeakVH to the BasicBlock. BasicBlock's are Value, so this will
invalidate properly and become nullptr.
2. Since, for the deleted blocks, you are mainly looking for the DT node
they referred to, store that at applyUpdates time.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20171016/7c6d51fa/attachment.html>


More information about the llvm-commits mailing list