GCC Bugzilla – Bug 29756
SSE intrinsics hard to use without redundant temporaries appearing
Last modified: 2006-11-21 05:44:07 UTC
I've been adapting some old codes' simple 4-float vector class to use SSE by use of the intrinsic functions. It seems to be quite hard to avoid the generated assembly code being rather diluted by apparently redundant spills of intermediate results to the stack.
On inspecting the assembly produced from the file to be attached, compare the code generated for matrix44f::transform_good and matrix44f::transform_bad.
The former is 20 instructions and apparently optimal. However, it was only arrived at by prodding the latter version of the function (which does exactly the same thing but expressed more naturally, but results in 32 instructions) until the stack temporaries went away. It would be nice if both versions of the function generated optimal code and there doesn't seem to be any particular reason they shouldn't.
Both versions' assembly contain the same expected numbers of shuffle, multiply and add instructions, the excess seems to all involve extra stack temporaries.
[I'm not sure what the "triplet" codes on this form are.
I'm using a gcc in Debian Etch gcc --version shows "gcc (GCC) 4.1.2 20060901 (prerelease) (Debian 4.1.1-13)"; platform is a Pentium3. Sorry if the "inline-asm" component is a completely inappropriate thing to assign to.]
Created attachment 12566 [details]
Result of gcc -v -save-temps -S -O3 -march=pentium3 -mfpmath=sse -msse -fomit-frame-pointer intrin.cpp
This is the .ii file output from
gcc -v -save-temps -S -O3 -march=pentium3 -mfpmath=sse -msse -fomit-frame-pointer intrin.cpp
Most of it is the result of the .cpp's sole direct include : #include <xmmintrin.h>, which was immediately before the "class vector4f" declaration.
Looks like this is mostly caused by:
I will have a look more at this issue later tonight when I get home from work.
I've just tried an alternative version (will upload later) replacing the union with a single
and implementing the  operators using e.g
However the code generated by the two transform implementations remains the same (20 and 32 instructions anyway; haven't checked the details yet).
Maybe not surprising as it's just moving the problem around.
The big difference between the two methods is perhaps primarily that the bad one involves a __v4sf->float->__vfs4 conversion, while the good one uses __v4sf throughout by using the mul_compN methods. I'll try and prepare a more concise test case based on the premise that bad handling of __v4sf <-> float is the real issue.
Created attachment 12573 [details]
More concise demonstration of the v4sf->float->v4sf issue.
The attached code, (no classes or unions, just a few inline functions) obtained from
gcc -v -save-temps -S -O3 -march=pentium3 -mfpmath=sse -msse -fomit-frame-pointer v4sf.cpp
compiles transform_good to 18 instructions and transform_bad to 33. However it's not really surprising a round-trip through stack temporaries is required when pointer arithmetic is being used to extract a float from a __v4sf. I've no idea whether it's realistic to hope this could ever be optimised away. Alternatively, it would be very nice if the builtin vector types simply provided a  operator, or if there were some intrinsics for extracting floats from a __v4sf.
(In the meantime, in the original vector4f class, remaining in the __v4sf domain by having the const operator return a suitably type-wrapped __v4sf "filled" with the specified component seems to be a promising direction).
This is mostly PR 28367. There are most likely other issues like some of the SSE intrinsics not being declared as pure/const.