Bug 29756 - SSE intrinsics hard to use without redundant temporaries appearing
SSE intrinsics hard to use without redundant temporaries appearing
Product: gcc
Classification: Unclassified
Component: middle-end
: P3 enhancement
: ---
Assigned To: Not yet assigned to anyone
: missed-optimization
Depends on: 28367
  Show dependency treegraph
Reported: 2006-11-07 22:22 UTC by Tim Day
Modified: 2006-11-21 05:44 UTC (History)
4 users (show)

See Also:
Known to work:
Known to fail:
Last reconfirmed:

Result of gcc -v -save-temps -S -O3 -march=pentium3 -mfpmath=sse -msse -fomit-frame-pointer intrin.cpp (74.79 KB, text/plain)
2006-11-07 22:26 UTC, Tim Day
More concise demonstration of the v4sf->float->v4sf issue. (72.23 KB, text/plain)
2006-11-08 22:18 UTC, Tim Day

Note You need to log in before you can comment on or make changes to this bug.
Description Tim Day 2006-11-07 22:22:55 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.]
Comment 1 Tim Day 2006-11-07 22:26:59 UTC
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.
Comment 2 Andrew Pinski 2006-11-07 22:31:26 UTC
Looks like this is mostly caused by:
    __v4sf vecf;
    __m128 rawf;
    float val[4];
  } _rep;

I will have a look more at this issue later tonight when I get home from work.

Comment 3 Tim Day 2006-11-08 10:01:11 UTC
I've just tried an alternative version (will upload later) replacing the union with a single
  __v4sf _rep,
and implementing the [] operators using e.g
  (reinterpret_cast<const float*>(&_rep))[i];
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.
Comment 4 Tim Day 2006-11-08 22:18:28 UTC
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).
Comment 5 Andrew Pinski 2006-11-14 01:15:11 UTC
This is mostly PR 28367.  There are most likely other issues like some of the SSE intrinsics not being declared as pure/const.