[macstl-dev] -faltivec without -maltivec copying;
gcc's altivec attributes
glen.low at pixelglow.com
Thu Aug 4 08:30:11 WST 2005
Compiling Altivec code on Apple gcc 4.0 with -faltivec but no -
maltivec produces more efficient code due to CSE, but has its own
problems. The compiler regularly inserts a non-inlineable call to
memcpy or memset when a structure containing a vector is copied (e.g.
in C++ through a trivial copy constructor), and then warns you with
"vectorised memcpy disabled due to use of -faltivec without -maltivec".
To the compiler writers: why can't the memcpy be inlined with non-
Altivec instructions and preserve the intent of leaving a non-Altivec
codepath? (The equivalent of _builtin_memcpy?)
The problem for me is that gcc often produces more efficient code
when it doesn't have a user-defined copy constructor -- almost all
the objects in macstl have no user-defined copy constructor because
of this -- presumeably because it provides more opportunities to
elide the copy. But the few occasions when it can't elide the copy,
the compiler pessimizes the code even more by inserting the non-
inlined call to memcpy. The only way I can avoid that is to define my
own copy constructor but I potentially lose general efficiency.
1. Any flags or options to get this memcpy inlined?
2. Any attributes I can tag on a structure so that it will have
the memcpy inlined?
3. Any macros or any other automatic way to detect if -faltivec
was invoked without -maltivec?
4. Looking at the output of "gcc -dM -E - -faltivec < /dev/null",
__attribute__ ((altivec (vector__)))
__attribute__ ((altivec (element__)))
__attribute__ ((altivec (bool__)))
__attribute__ ((altivec (pixel__)))
I didn't find these attributes documented anywhere.
Cheers, Glen Low
pixelglow software | simply brilliant stuff
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the macstl-dev