[PATCH] D32614: [GVNHoist] Fix: PR32821, add check for anticipability in case of infinite loops

[Daniel Berlin via llvm-commits]

On Mon, May 8, 2017 at 2:59 PM, Aditya Kumar via Phabricator <
reviews at reviews.llvm.org> wrote:

> hiraditya added a comment.
>
> In https://reviews.llvm.org/D32614#740129, @dberlin wrote:
>
> > In https://reviews.llvm.org/D32614#740119, @hiraditya wrote:
> >
> > > In https://reviews.llvm.org/D32614#739947, @dberlin wrote:
> > >
> > > > I'm at a loss to understand why you believe you need to compute
> joint post-dominance (which is what this is) to compute ANTIC.
> > >
> > >
> > > If the set of BasicBlocks (WL) do not joint-post-dominate the hoisting
> point (HoistBB), then the expression to be hoisted (from WL) cannot be
> ANTIC in HoistBB.
> >
> >
> > Sure.
> >  That is definitely a way of computing it.
> >  It is a generally slow and unused way of computing it, because there
> are only certain points in the SSA graph where ANTIC can actually change.
> >
> > > It is a necessary condition what I'm checking here.
> >
> > It is not necessary to perform graph reachability to do this.
> >
> > https://pdfs.semanticscholar.org/6d0f/07ff330402b46e83d46142e202069d
> 9aeceb.pdf
> >
> > Stare at the down-safety step.
> >  With a few bits, it is only actually necessary to compute and check
> antic at the possible phis you would insert to do your hoisting.
>
>
> From the paper and the book (http://ssabook.gforge.inria.
> fr/latest/book.pdf page: 151), it seems DownSafety algorithm does exactly
> what I'm doing in the function (anticReachable), IIUC.
>
>
It does so only by walking the actual redundancy graph, actually.



> DownSafety:
> ...
> 10: for each f ∈ {Φ’s in the program} do
> 11:   if ∃ path P to program exit or alteration of expression along which
> f is not used
> 12:      downsafe (f ) ← false
> ...
>
> It checks for each path from point P to the program exit. They have
> simplified the problem by assuming that end of the function is reachable
> from every node which is not the
> case with LLVM representation of CFG (and that caused the bug).
>
They have exactly the same representation we do, actually (i've looked at
the code :P)
;)



> If I implement the ANTIC the way they have done, it would require
> iterating through all dominance frontiers to figure out PHI insertion
> points.
>

Errr, you already need to know the insertion points to do hoistnig/sinking
anyway!

Also, just ensuring downSafety at the PHI is not sufficient to guarantee
> downsafety at HoistPt because there might be safety issues between a
> definition of instruction and its dominance frontier.
>
>
They mark this in the redundancy graph.

My point in all this is that repeatedly redoing computation over all
possible expressions to be hoisted, instead of computing some sort of
factored graph of relevant points like they do, means you are computing
this repeatedly and expensively.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170508/e8ab6290/attachment.html>