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

[Andrew Haley <aph at redhat dot com>]

Stuart Hastings writes:
 > 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.

You have the same problem with Java -- you're stepping through a Java
program, and all of a sudden you're inside the memory allocator.  What
we _really_ need is some way to tell gdb "I'm debugging my own
program, not the library" or somesuch.  Or, and this is less
desirable, some way to persuade gcc not to output debug info inside
some inlined functions, although I can't image how a priori you'd
decide which ones.

But macros are a Bad Thing for all kinds of reasons, and going from
inlines to macros is a major step backwards just to get rid of debug
information!

Andrew.