target/10691: Invalid assembly emitted when using _m128 datatypes on x86

[Kevin J Bowers]

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=10691

Brief followup:

I've had the problem crop up in a couple of other situations. Here is 
some information that might help in isolating the problem.

Consider _mm_storel_pi in "xmmintrin.h":

static __inline void
_mm_storel_pi (__m64 *__P, __m128 __A)
{
   __builtin_ia32_storelps ((__v2si *)__P, (__v4sf)__A);
}

In a -g compile, it appears that the the macro is not expanded inline. 
For the function call, the compiler puts the arguments on the stack as:

(%esp)  -> __P
4(%esp) -> __A

To store the caller's __A at 4(%esp), the compiler emits something along 
the lines of:

movaps mem128, %xmm_reg
movaps %xmm_reg, 4(%esp) ==> faults
...
call _mm_storel_pi

At higher optimization levels, sometimes the faulting move gets 
optimized away and sometimes it doesn't.

I suspect that the faults will go away if __m128 arguments in a function 
call are placed such that they fall on 16-byte boundaries. In the above 
example, this would mean switching the order of __P and __A arguments. 
In any case, the faults seems to go away if I override the various 
xmmstore macros to byass the inline intrinsic functions.

That is:

#define _mm_storel_pi(__P,__A) \
   __builtin_ia32_storeaps((__v2si *)__P, (__v4sf)__A)

The preferred solution is that __m128 arguments put onto the stack be 
placed on 16-byte boundaries. I solution that would work (but that would 
defeat the point of using SSE instructions) would be to use a "movups" 
to put the __m128's onto the stack.

A previous response says that this problem might have been fixed. Does 
this mean fixed in gcc-3.3? I've had this problem in gcc-3.2.x.

-- 
Kevin J Bowers, Ph.D.
Plasma Physics Group (X-1)
Applied Physics Division
Los Alamos National Lab