[PATCH] Add control dependence computation that computes control dependence equivalence classes.

[Daniel Berlin]

Actually, I thought of a case that won't work with that formulation:

Given
int a, b;
int main(void)
{
    do {
        do {
           b = a +1;
       }
            while (b);
    } while (a);
    return 0;
}


b = a+ 1 is control dependent on both the while test edges.
Both both loops are in the same CDEQ set (for the same reason. In fact,
simplifycfg will just make one single huge loop out of this.  )

So when you have things that are control dependent on multiple nodes in
nested loops, you won't be able to determine both of the edges it's
dependent on, since the equivalence class is essentially the set that is
result of an equality query.  So you can't recover CD directly from it.
You can recover info about CONDS from it, you just don' t know what the
answer is.

That is, CDEQ(w) is exactly the set of of things {for all blocks v in CFG |
CONDS(v) == CONDS(w)}

So you know that things in the same set must have the same CONDS, you just
don't know what that CONDS is.

However, you do know the answer to what CONDS is limited to the edges
between the CDEQ blocks, and the boundary edges of the CDEQ blocks (IE the
edges to a different equivalence class).

I would bet you could compute this in linear time from CDEQ.
>From CONDS, you can get CD.

Though I admit, i'm curious what you would want the CD sets for.
Most things i've seen really want control-region info (so they can treat
all things equivalent as one large basic block) or things like SESE regions
(which can be computed in linear time from these sets) or the program
structure tree or whatever.
These are all computable directly from these sets.




On Mon, Mar 30, 2015 at 10:36 AM, Daniel Berlin <dberlin at dberlin.org> wrote:

>
>
> On Tue, Mar 24, 2015 at 10:12 AM, Adam Nemet <anemet at apple.com> wrote:
>
>> ================
>> Comment at: test/Analysis/ControlDependence/testdiamond.ll:4-14
>> @@ +3,13 @@
>> +target datalayout = "e-i64:64-f80:128-n8:16:32:64-S128"
>> +define void @testdiamond() {
>> +start:
>> +    br i1 true, label %same, label %different
>> +same:
>> +    br label %returnit
>> +different:
>> +    br label %returnit
>> +returnit:
>> +    ret void
>> +}
>> +; CHECK: ({different},{same},{returnit,start})
>> +
>> ----------------
>> Hi Danny,
>>
>> Quick question, is this control equivalence or control dependence?
>
>
> They are CDEQ sets, so control dependence equivalence :)
>
> We can call it whatever we want.
>
>
>>   Without looking at the details, it looks more like control equiv to
>> me.  Can this analysis also provide control dependence?
>>
>
> Without thinking too hard, you should be able to calculate the other sets
> from where the equivalence classes change.
>
> IE the edge which leads from one equivalence class to another.
>
>
>
>>
>> Also probably a silly question, but aren't 'different' and 'same'
>> control-equiv here?  They both seem to be control-depended on start, no?
>>
>>
> No, because it's not really nodes but edges (because they are CDEQ sets,
> which are made up of edges)
>
> The edge (start, different) is a different edge than (start, same), so
> they are not dependent on the same edge.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150330/92a92e2e/attachment.html>