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

> 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?
>
Yes, but ...

It's not always as obvious as dominators is as to what changes.  For
simple code changes, yes.
But in some of the more complex cases we correctly perform dominator
updates, either someone has to think really hard about it, or you have
to eat the recalc cost.  Not that i'm opposed to hard thinking :)

But to put difficulty (or maybe laziness, depending on what you think
:P) into perspective:
There is exactly one pass in GCC that actually updates post-dominators.
The rest recalculate it from scratch, every pass.  it's uh, pretty impressive.
So if the answer is "the cost of post-dom is too high", either we need
to make post-dom faster, or implement updating.

Generalized, "nobody has to think about it" updating can be done by
using DJ-graphs (which we already use in promotememorytoregisters to
do linear time phi placement) such that edge insertion is O(|a subtree
of the graph affected by the edge|), which is probably pretty darn
fast in practice.

But edge deletion is O(|n^2|) in this update method, and O(|some other
crappy numbers|) in most others.
I expect that edge deletion in those cases is worse than recalculation
in practice.

Now, that said, most *common* operations the post-dom updates we do
are going to be pretty obvious.
I'd expect you end up with a recalc point before and after serious
loop opts, which isn't that bad.

But, to give you some idea of time-taking. Post-dom calculation takes
about 0.5 seconds for one of my large .bc files.  It's mostly in the
eval routine.  Doing this twice is not that bad, compile-time wise.

This pass i implemented takes 0.4 seconds, of which 0.25 seconds is
memory allocation and freeing :)
It would be hard to make it faster once if i get rid of that time taking.


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