[cfe-commits] r47850 - /cfe/trunk/Headers/mmintrin.h

[Devang Patel]

>> why does always_inline matter, though?
>
> Because users expect them to be inlined.  When debugging for example,
> they want to know they are in routine foo, if they are in routine foo,
> even when there is little debug information.


Users treat this intrinsics as if they are machine instructions  
directly.

1) This means, they do not want to pay function call overhead in any  
case. Here, the always_inline attribute informs inline to inline  
functions irrespective of what inlining heuristics says.

2) Since, they treats these intrinsics as instructions, they expect  
profilers (e.g. Shark on Mac OS X) to account resources spent here in  
the function that called these intrinsics.

	For example, they want to know function foo() in source.cpp consumes  
xyz machine cycles not _mm_packs_pu16() in mmintrin.h. Now, even  
though _mm_packs_pu16() is inlined by optimizer, profiler (through  
debug info in Shark's case) knows that it is actually defined in  
mmintrin.h and counts cost accordingly, which is not what user  
expected. Here nodebug attribute informs compiler to not emit  
debugging info for this "special" function.

-
Devang