[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...

Daniel Berlin dberlin at dberlin.org
Mon Mar 30 17:09:16 PDT 2015


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.


> 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
>




More information about the llvm-commits mailing list