This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: How do you get the benefit of -fstrict-aliasing?
- From: Bradley Lucier <lucier at math dot purdue dot edu>
- To: gcc mailing list <gcc at gcc dot gnu dot org>
- Cc: Marc Feeley <feeley at iro dot umontreal dot ca>, Bradley Lucier <lucier at math dot purdue dot edu>
- Date: Fri, 18 May 2007 12:00:06 -0400
- Subject: Re: How do you get the benefit of -fstrict-aliasing?
- References: <DE53BA17-8720-4015-8F87-B5D201323D86@math.purdue.edu>
On Apr 21, 2007, at 6:01 PM, Bradley Lucier wrote:
So I'm wondering whether certain options have to be included on the
command line to get the benefits of -fstrict-aliasing.
I've thought about this question a bit more, so maybe I can make it
less content-free.
The C code generated by Gambit-C, the Scheme->C compiler, has certain
somewhat strange characteristics, mainly because it's targeted to a
simulated virtual machine implemented using C macros. Experimental
results show that simply using gcc -O2 or -O3 results in
significantly suboptimal code; gcse generally makes the code
noticeably worse, for example. So we pick and choose our gcc
optimization options.
The generated code also has significant opportunities to exploit
alias information---words on the stack cannot alias the car or cdr of
a pair, the contents of a vector, etc. The macros implementing the
virtual machine can be tweaked to make more of that information
explicit, and I'd like gcc to exploit that information, so I'm
wondering which optimizations make particular use of aliasing
information. Perhaps I've left those off the gcc command line.
Until now, I have used -fno-strict-aliasing in the code for
correctness reasons (some of the virtual machine macros, related to
the bignum library and written in a style similar to assembly, have
aliasing violations). When I add -fstrict-aliasing when compiling
user code (which doesn't use the bignum macros), I sometimes get
significantly slower code. Perhaps there is a lot more register
pressure as Andrew suggested, but looking at the assembly output
doesn't seem to justify this assumption (basic blocks are small and
somewhat independent, it's running on a register-rich machine [64-bit
PowerPC], etc.).
Brad