Re: OT: alias options in gcc?
Re: OT: alias options in gcc?
- Subject: Re: OT: alias options in gcc?
- From: Chris Rogers <email@hidden>
- Date: Tue, 26 Nov 2002 13:33:02 -0800
Here's some more information which may be helpful since we've had to
deal with this issue. The nasty case in Stephen's example below
is when MyVectorFunc() is NOT declared inline and yet the compiler
decides to inline the function anyway!! If you put the function
MyVectorFunc () in a separate source file from MyFunc()
(and don't declare MyVectorFunc() as inline just to be safe)
then I've found that gcc will never inline MyVectorFunc().
I don't know enough about the compiler/linker to guarantee that this
will *always* solve the problem, but it has always worked for me.
Also, we've found that using -O3 optimization tends to work well
for our DSP code. I haven't experienced any cases of bad code gen.
Chris Rogers
Core Audio
Apple Computer
If that function contains altivec code then there is probably some
prolog/epilog code for saving/restoring the altivec registers used
by the code and those instructions will get executed on the G3 and
kaboom! Since the compiler is free to do its register saving
anywhere it wants to, you can't assume that code like this will not
blow up on a G3.
void MyFunc( float * data, int numSamples, bool useAltivec )
{
if ( useAltivec )
{
vector float * fp = (vector float *) data;
... do some vector stuff
}
else
{
... do some scalar stuff ...
}
}
Even if the vector variables are all properly scoped the compiler
will do its save/restore stuff outside the block so you're not safe.
OR
inline void MyVectorFunc( vector float * data, int numSamples )
{
... do some vector stuff ...
}
void MyFunc( float * data, int numSamples, bool useAltivec )
{
if ( useAltivec == true )
MyVectorFunc( (vector float *) data, numSamples );
else
... do scalar stuff ...
}
If MyVectorFunc() gets inlined then you are cheesed.
Hope that helps,
stephen
On Tuesday, November 26, 2002, at 12:35 PM, Kurt Bigler wrote:
on 11/26/02 12:01 PM, Bill Stewart <email@hidden> wrote:
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
Do you really mean "executing"? It doesn't make sense to me that inlining
would change what code gets executed. It seems conceivable that inlining
might cause altivec code to be included in a function intended to be
non-altivec only.
-Kurt Bigler
_______________________________________________
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.
_______________________________________________
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.