[macstl-dev] -faltivec without -maltivec copying; gcc's altivec attributes

[Glen Low]

Dear All

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.

Further questions:

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",  
what is:

__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
www.pixelglow.com
aim: pixglen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.pixelglow.com/lists/archive/macstl-dev/attachments/20050804/6f3b1f92/attachment.html