[prev in list] [next in list] [prev in thread] [next in thread]
List: gcc
Subject: Re: Importance of transformations that turn data dependencies into control dependencies?
From: Jeff Law <law () redhat ! com>
Date: 2016-02-26 20:41:27
Message-ID: 56D0B877.7030701 () redhat ! com
[Download RAW message or body]
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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic