x86 Q: why aren't the SSE intrinsics always_inline?

[Stuart Hastings <stuart at apple dot com>]

Subject says it all.

IIUC, the SSE intrinsics are made available as functions because  
that's the least-broken way to support them in a target-agnostic  
compiler.  They're clearly intended to be fully inlined in normal  
usage.  And they're marked "inline," but not "always_inline."

Why?

Perhaps there's a usage model I'm unfamiliar with, where these are  
best left as callable (breakpoint-able?) functions.  But most usage  
I've seen is inside hand-crafted, time-critical loops, where the  
programmer wants the XYZ vector operation, and really doesn't want to  
see or know about the function body wrapper hiding a builtin.

I've received lots of ... comments about this here at Apple :-) .   
The latest suggests we return to a macro-based implementation because  
it avoids the step-into-intrinsicA-step-into-intrinsicB mental gear- 
changing as GDB faithfully follows the debug info.  (One Apple  
programmer has abandoned xmmintrin.h in favor of his own SSE  
macros.)  This seems to be an impediment for vector developers, as  
they don't want to see the bodies of these intrinsics; they want to  
see their own code, where they wrote "vec_a = vec_plus(vec_b,  
vec_c)."  When Apple developers examine their programs with profiling  
data using "Shark," an Apple proprietary tool, the profiling  
information attached to these functions is resented, as it creates  
false "hot spots."  It's been argued this should be fixed in "Shark,"  
but nobody has stepped forward to say "I need to know how many times  
I used the SSE XYZ opcode."

I'm not sure it's the example to follow, but this is handled  
differently in altivec.h; Apple's version seems to rely on  
"always_inline," and FSF's version seems to use macros.  Should [xpe] 
mmintrin.h be similar to one of these?

stuart hastings
Apple Computer