Re: Importance of transformations that turn data dependencies into control dependencies?

[Jeff Law <law at redhat dot com>]

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