Importance of transformations that turn data dependencies into control dependencies?

[Jeff Law]

On 02/24/2016 05:14 AM, Richard Biener wrote:

> Note that if a user writes
>
>    if (p == d)
>     {
>       ... do lots of stuff via p ...
>     }
>
> GCC might rewrite accesses to p as accesses to d and thus expose
> those opportunities.  Is that a transform that isn't valid then or is
> the code written by the user (establishing the equivalency) to blame?
I think Torvald later clarified this wasn't a problem.  If it was, then 
it wouldn't be hard to disable this for pointers and I doubt the impact 
would be measurable.

>
> There's a PR where this kind of equivalencies lead to unexpected (wrong?)
> points-to results for example.
Yea, I've watched a couple discussions around this issue.  I don't 
recall them reaching any conclusion about the validity of the testcases.

If the final determination is that such equivalence propagation is 
unsafe for the points-to aliasing system, we can just disable those 
pointer equivalence tracking bits.

>
>> Other potential examples that come to mind are de-virtualization, or
>> feedback-directed optimizations that has observed at runtime that a
>> certain pointer is likely to be always equal to some other pointer (eg.,
>> if p is almost always d[0], and specializing for that).
>
> That's the cases that are quite important in practice.
I was most concerned about de-virt and feedback stuff that specializes 
paths based on expected values.


Jeff