llvm-gcc is overly pessimistic of union alignment

[llvmbot]

Bugzilla Link	3432
Resolution	FIXED
Resolved on	Mar 06, 2010 13:59
Version	trunk
OS	All
Reporter	LLVM Bugzilla Contributor

Extended Description

#include <xmmintrin.h>

typedef union
{
int i[4];
float f[4];
__m128 v;
} vector4_t;

__m128
swizzle (const void *a, vector4_t * b)
{
return _mm_loadl_pi (b->v, (__m64 *) a);
}

On x86 / Mac OS X, this compiles to:

target triple = "i386-apple-darwin9.6"
%struct.vector4_t = type { <4 x float> }

define <4 x float> @​swizzle(i8* nocapture %a, %struct.vector4_t* nocapture %b) nounwind readonly {
entry:
%0 = getelementptr %struct.vector4_t* %b, i32 0, i32 0 ; <<4 x float>> [#uses=1]
%1 = load <4 x float> %0, align 4 ; <<4 x float>> [#uses=1]
%tmp.i = bitcast i8* %a to double* ; <double*> [#uses=1]
%tmp1.i = load double* %tmp.i ; [#uses=1]
%2 = insertelement <2 x double> undef, double %tmp1.i, i32 0 ; <<2 x double>> [#uses=1]
%tmp2.i = bitcast <2 x double> %2 to <4 x float> ; <<4 x float>> [#uses=1]
%3 = shufflevector <4 x float> %1, <4 x float> %tmp2.i, <4 x i32> < i32 4, i32 5, i32 2, i32 3 > ; <<4 x float>> [#uses=1]
ret <4 x float> %3
}

Notice the alignment of the load instruction is 4. This is overly strict. We ended up issuing a movups instead of a movaps.

[lattner]

This was an llvm-gcc bug that may be a regression caused by the lvalue alignment stuff. Evan, I checked in some patches for this, please commit the testcase, thanks!

[lattner]

This was an llvm-gcc bug that may be a regression caused by the lvalue
alignment stuff. Evan, I checked in some patches for this, please commit the
testcase, thanks!