Davide Ancri wrote:
Ryan Mansfield wrote:
Is there an optimization options for gcc to obtain the same “-oa” wcc
behaviour?
-fno-strict-aliasing
I quote here a part of my thread-heading post:
As far as I can understand from manuals and “info” pages, the two
optimizations only share the “aliasing” word, but operates on completely
different scenarios.
The -fstrict-aliasing (and related couterpart -fno-strict-aliasing, that
disable the optimization) impact on accesses made on unions through
pointers to types not being exactly of the same union, but of a member
of that union (it’s not so simple to explain the sense with my poor
english, but the example on gcc info pages are nearly clear).
-fstrict-aliasing is not limited to this one optimization. The gcc page
explains what the option does. “Allows the compiler to assume the
strictest aliasing rules applicable to the language being compiled.”
Aliasing rules were designed to allow compilers to do more aggressive
optimization. Basically, a compiler can assume that all changes to
variables happen through pointers or references to variables of a type
compatible to the accessed variable. For example, dereferencing a
pointer that violates the aliasing rules results in undefined behavior.
These rules are defined by the C and C++ standards. -fstrict-aliasing
tells gcc to assume that your code follows the standard and is then able
to perform more optimizations. For example, when you specify
-fno-strict-aliasing, when calculating its alias set gcc has to assume
that everything aliases everything else. I suppose this could be
considered ‘relaxing’ the aliasing rules as it allows pointers to
variables that are not type compatible. By having a smaller alias set,
there are less aliases, and if two addresses are shown not to alias,
redundant load/store and code scheduling can be removed.
The options are similar in the sense that both they instruct the
compiler to either enforce, or relax the aliasing rules. Yes, the
individual optimizations done by each compiler are going to be different
regardless of whether or not the aliasing rules are being enforced. But
it is not the compiler’s fault if you tell the compiler ‘my code
conforms’ (-fstrict-aliasing) and your code doesn’t, then gcc generates
ends up generating unexpected code.
The same code that works like a charme on “wcc -oeaxt” sometimes give us
problems with “gcc -O3” (that implies -fstrict-aliasing), but works well
with “gcc -O3 -fno-strict-aliasing”.
This is the reason I am trying to understand something more about this
kind of optimization!
Your best bet is tack down the violations and fix them. You should
be able to use -Wstrict-aliasing to catch most cases. Problems arising
from alias violations happen to be the #1 invalid PR filed against most
commercial compilers. See http://gcc.gnu.org/bugzilla/duplicates.cgi as
an example. Since detecting these violations is so important and
frequent, in gcc 4.0 -Wstrict-aliasing=2 was added to catch more of
these aliasing problems but will not catch all cases.
Regards,
Ryan Mansfield
