This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: strict aliasing benefit examples


> The best examples would involve optimizations which
> could not be performed if gcc did what people normally
> expect from a simple pointer cast and wrong-type access.
> I doubt such examples exist, but I hope they do.

Simple examples exist and I see that later in this thread you were sent
one of the classic ones.

The harder question to answer is how often such optimization opportunities
occur in real code.  Compiler writers always tend to assume that
optimizations are more helpful than they really are.  There are a number of
counterbalancing issues here:

(1) C isn't a very strongly-typed languages and in common usage C++ isn't a
whole lot more so.  That means that there are very few distinct alias classes
for scalars in most programs.  And aliasing optimizations are more valuable
for scalars than aggregate types.

(2) One might think that a more strongly-typed language such as Ada would
benefit more from this because there will normally be lots of distinct scalar
alias classes, but the use of pointers (access types) in Ada is relatively
rare in most code and that's where most of the optimization opportunities
come from.

(3) Alias analysis isn't an optimization per se, but is a tool in determining
when two references can't conflict, meaning that it's important for numerous
optimizations, such as CSE, loop invariant analysis, instruction scheduling,
etc.  So as compilers get more sophisticated, the value they can obtain from
knowing that two references don't conflict increases.

(4) On the other hand, as compilers get more sophisticated, there become
other ways of determining that two references can't conflict other than alias
analysis, for example value tracking and interprocedural optimizations.
Nevertheless, there will still be cases (such as the example given later in
this thread) where alias analysis is the only way to do an optimization.

I think the bottom line here is that compiler writers want to be able to take
advantage of any freedom that the language standard allows in order to do as
much optimization as possible, the language standard was specifically written
with this optimization issue in mind, and there are fairly straightforward
ways of writing incorrect code in ways consistent with the standard.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]