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

[Aditya K via llvm-commits]

>> 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)
In case of infinite loop the end of the function is not reachable from within the loop, in the dominator tree, otherwise this bug would not have happened.

> Errr, you already need to know the insertion points to do hoistnig/sinking anyway!
> 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.

PHI insertion points are same as down safety points for (partially) available expressions but for hoist points we would also have to check
down safety from the hoist-point to the PHI insertion point. I agree that having a factored graph may reduce the complexity of GVNHoist.
It seems like I would have to implement several parts of what GVN-PRE infrastructure could already have.
Would it be a good idea to integrate this with GVN-PRE (like gcc)?

Thanks for the feedback and review,
-Aditya



From: Daniel Berlin <dberlin at dberlin.org>
Sent: Monday, May 8, 2017 4:48 PM
To: reviews+D32614+public+2b3a6528323900c1 at reviews.llvm.org
Cc: Aditya Kumar; Sebastian Pop; Chandler Carruth; Davide Italiano; Geoff Berry; llvm-commits
Subject: Re: [PATCH] D32614: [GVNHoist] Fix: PR32821, add check for anticipability in case of infinite loops
  





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/07ff330402b46e83d46142e202069d9aeceb.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.