[PATCH] Add control dependence computation that computes control dependence equivalence classes.Unlike other implementations commonly found, this does not require either a post-dominatortree or post-dominance frontiers.It computes the relationship in...

[Hal Finkel]

----- Original Message -----
> From: "Daniel Berlin" <dberlin at dberlin.org>
> To: "Gerolf Hoflehner" <ghoflehner at apple.com>
> Cc: reviews+D8568+public+f0c1e6d4e76097cb at reviews.llvm.org, "Chandler Carruth" <chandlerc at gmail.com>, "Hal Finkel"
> <hfinkel at anl.gov>, "llvm commits" <llvm-commits at cs.uiuc.edu>
> Sent: Monday, March 30, 2015 7:09:16 PM
> Subject: Re: [PATCH] Add control dependence computation that computes control dependence equivalence classes.Unlike
> other implementations commonly found, this does not require either a post-dominatortree or post-dominance
> frontiers.It computes the relationship in...
> 
> On Mon, Mar 30, 2015 at 3:54 PM, Gerolf Hoflehner
> <ghoflehner at apple.com> wrote:
> > Hi Daniel,
> > Is avoiding pdom cost your major motivator for choosing the cycle
> > equivalence/PST algorithm?
> 
> Yes.
> Over the years everything pdom related has been removed from LLVM,
> and
> pdoms have been removed from almost every pass that used them (if not
> every one, i didn't check).
> 
> If that changes, i'd be glad to help fix that where i can, and go
> that route :)
> 
> > If the pdom issues were solved would you pick APT over PST?
> >
> Yes.
> 
> Note of course, i don't actually build PST's, i just use the numbers.
> 
> To give you some background, GVN propagates equalities from edges
> into
> dominating blocks.  Except, this of course is the wrong model, since
> it really wants to propagate equalities into regions that are
> controlled by the same condition.  This is not the same as normal
> dominance, and it currently punts on edge cases and a lot of things ,
> because they are slow to handle in this world. It also seriously
> limits what it can do.
> It will never, for example, notice that two predicates combine except
> by luck. It also can't handle equalities on edges that lead to blocks
> with multiple predecessors, because it doesn't know where they should
> be valid (it currently just substitutes them into their existing uses
> if they are dominated by the root block, and skips those with
> multiple
> preds).
> 
> The algorithm new GVN is based on actually has a "real" predicate
> system that uses control dependence, but I modified it to use the
> same
> equality propagation model old GVN uses. It would be nice to not do
> this :)
> 
> Other things, for example, a patch by Sanjoy to SCEV, has the same
> issue with loop latches. They use dominance as a shortcut for "things
> that this condition controls".  If you start to handle some of the
> edge cases, dominance becomes a very slow way of doing this.
> 
> > No preference implied. I’m only curious about what motivated your
> > choice
> >
> I went with what I thought I could get in, given the state of the
> world :)
> If we change the architecture to the point we love PDOM's again, that
> would clearly be a better  choice in terms of broader use cases.

I don't want to get things too side tracked, but what would this take? Is it "simply" a matter of teaching passes to preserve them?

 -Hal

> 
> 
> > Also, is nGVN the only client you envision currently?
> 
> Yes, but it could be used elsewhere if someone wanted it.
> 
> 
> >
> > Thanks
> > Gerolf
> >
> >> On Mar 23, 2015, at 3:46 PM, Daniel Berlin <dberlin at dberlin.org>
> >> wrote:
> >>
> >> - Sigh, here are the tests
> >>
> >> Updating D8568: Add control dependence computation that computes
> >> control dependence equivalence classes.
> >> ========================================================================================================
> >>
> >> Unlike other implementations commonly found, this does not require
> >> either a post-dominator
> >> tree or post-dominance frontiers.
> >> It computes the relationship in...
> >>
> >>
> >> http://reviews.llvm.org/D8568
> >>
> >> Files:
> >>  include/llvm/Analysis/ControlDependence.h
> >>  include/llvm/Analysis/Passes.h
> >>  include/llvm/InitializePasses.h
> >>  include/llvm/LinkAllPasses.h
> >>  lib/Analysis/Analysis.cpp
> >>  lib/Analysis/CMakeLists.txt
> >>  lib/Analysis/ControlDependence.cpp
> >>  test/Analysis/ControlDependence/testdiamond.ll
> >>  test/Analysis/ControlDependence/testembeddeddiamond.ll
> >>  test/Analysis/ControlDependence/testifinloop.ll
> >>  test/Analysis/ControlDependence/testloop.ll
> >>  test/Analysis/ControlDependence/testnomergebranch.ll
> >>  test/Analysis/ControlDependence/teststraightline.ll
> >>
> >> EMAIL PREFERENCES
> >>  http://reviews.llvm.org/settings/panel/emailpreferences/
> >> <D8568.22526.patch>_______________________________________________
> >> llvm-commits mailing list
> >> llvm-commits at cs.uiuc.edu
> >> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> >
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory