Re: OT: alias options in gcc?
Re: OT: alias options in gcc?
- Subject: Re: OT: alias options in gcc?
- From: Bill Stewart <email@hidden>
- Date: Tue, 26 Nov 2002 12:01:25 -0800
We build with 03 - you'd have to be doing some pretty nasty things I
think to be busted by this option and we do notice a difference for our
DSP projects when we do this - the thing we most get bitten by here is
the proclivity of the compiler to inline code with O3 and small stub
routines that have altivec code ending up executing on a G3 - which is
not a good thing:)
Another strongly recommended option with gcc 3 is 0s... that is
slightly more otpimised than O2, but without some of the more
aggressive optimisations of O3, far less inlining so the overall code
size is smaller - this is typically the setting we use unless we're
dealing with critical path code (like AUs tend to be)
Bill
On Tuesday, November 26, 2002, at 01:49 AM, Herbie Robinson wrote:
Slight OT I know - I'm moving some DSP algorithms across to OSX and
having
done some quick performance testing it has become apparent that the
default
deployment gcc settings aren't being very aggressive when optimising
the
code in my inner loops. The main problem is aliasing between my
process
buffers (which are float *) and member variable of the enclosing
class.
I can solve the problem by declaring local variables outside my inner
loops
which contain copies of the referenced member variables in the inner
loop,
but there is a lot of code to update if this is the only solution...
Anyone know what compiler settings I should try for gcc to change its
aliasing policy? I'm running the August ProjectBuilder update on
10.2.2.
Regards,
Cesare
The GCC optimization option is -On (that's a capital letter O followed
by a digit). The default is zero (none). The advice I've gotten is
that up to -O2 is safe. Beyond that, programs start breaking.
The aliasing assumption you want the compiler to make is, in fact, not
safe in C. If none of the code you are compiling ever uses a cast,
then maybe some more assumptions can be made about aliasing.
Unfortunately, I haven't seen much code that doesn't have a cast
someplace in it. More to the point, a lot of the OS header files use
aliasing. Because of things like aliasing, a C compiler pretty much
has to assume that you have modified everything except automatic and
local static whenever you assign through a pointer.
The way to get good code that remains transportable (and also works
with the next release of the compiler) is to copy things that you know
aren't changing into local variables. If you name the local variables
well, the code will probably be easier to read, too.
--
-*****************************************
** http://www.curbside-recording.com/ **
******************************************
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.
--
mailto:email@hidden
tel: +1 408 974 4056
________________________________________________________________________
__
"Much human ingenuity has gone into finding the ultimate Before.
The current state of knowledge can be summarized thus:
In the beginning, there was nothing, which exploded" - Terry Pratchett
________________________________________________________________________
__
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.