#include <xmmintrin.h>
#include <math.h>
#include <emmintrin.h>

Include dependency graph for README-SSE.txt:

Typedefs
using	t = bitcast float %x to i32 %s=and i32 %t, 2147483647 %d=bitcast i32 %s to float ret float %d } declare float @fabsf(float %n) define float @bar(float %x) nounwind { %d=call float @fabsf(float %x) ret float %d } This IR(from PR6194):target datalayout="e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64-S128" target triple="x86_64-apple-darwin10.0.0" %0=type { double, double } %struct.float3=type { float, float, float } define void @test(%0, %struct.float3 *nocapture %res) nounwind noinline ssp { entry:%tmp18=extractvalue %0 %0, 0

Functions
SSE Variable shift can be custom lowered to something like which uses a small table unaligned load shuffle instead of going through memory __m128i	shift_right (__m128i value, unsigned long offset)

float	f32 (v4f32 A)

into xmm2 addss xmm2 xmm1 xmm3 addss xmm3 movaps xmm0 unpcklps xmm0 ret seems silly when it could just be one addps Expand libm rounding functions main should enable SSE DAZ mode and other fast SSE modes Think about doing i64 math in SSE regs on x86 This testcase should have no SSE instructions in and only one load from a constant double ret double C the select is being which prevents the dag combiner from turning	select (load CPI1)

into xmm2 addss xmm2 xmm1 xmm3 addss xmm3 movaps xmm0 unpcklps xmm0 ret seems silly when it could just be one addps Expand libm rounding functions main should enable SSE DAZ mode and other fast SSE modes Think about doing i64 math in SSE regs on x86 This testcase should have no SSE instructions in and only one load from a constant double ret double C the select is being which prevents the dag combiner from turning load CPI2	load (select CPI1, CPI2)' The pattern isel got this one right. Lower memcpy/memset to a series of SSE 128 bit move instructions when it 's feasible. Codegen

return	_mm_set_ps (0.0, 0.0, 0.0, b)

This might compile to this xmm1 xorps xmm0 movss xmm0 ret Now consider if the code caused xmm1 to get spilled This might produce this xmm1 movaps	c2 (%esp) ... xorps %xmm0

This might compile to this xmm1 xorps xmm0 movss xmm0 ret Now consider if the code caused xmm1 to get spilled This might produce this xmm1 movaps xmm0 movaps xmm1 movss xmm0 ret since the reload is only used by these we could fold it into the producing something like xmm1 movaps xmm0 ret saving two instructions The basic idea is that a reload from a spill if only one byte chunk is bring in zeros the one element instead of elements This can be used to simplify a variety of shuffle where the elements are fixed zeros This code generates ugly probably due to costs being off or< 4 x float > eax	movaps (%eax)

void	x (unsigned short n)

void	y (unsigned n)

compile	to (-O3 -static -fomit-frame-pointer)

This currently compiles esp	movsd (%esp)

This currently compiles esp xmm0 movsd esp	movl (%esp)

This currently compiles esp xmm0 movsd esp eax eax esp ret We should use not the dag combiner This is because dagcombine2 needs to be able to see through the X86ISD::Wrapper which DAGCombine can t really do The code for turning x load into a single vector load is target independent and should be moved to the dag combiner The code for turning x load into a vector load can only handle a direct load from a global or a direct load from the stack It should be generalized to handle any load from where P can be anything The alignment inference code cannot handle loads from globals in static non mode because it doesn t look through the extra dyld stub load If you try vec_align ll without relocation you ll see what I mean We should lower	store (fneg(load p), q) into an integer load+xor+store

vSInt16	madd (vSInt16 b)

Generated	code (x86-32, linux)

__m128	foo1 (float x1, float x4)

gcc mainline compiles it	x2 (%rip)

gcc mainline compiles it xmm0	x3 (%rip)

into eax xorps xmm0 xmm0	movzbl (%esp)

into eax xorps xmm0 xmm0 eax xmm0 eax xmm0 ret esp eax movdqa xmm0 xmm0 esp const ret align it should be movdqa	LC0 (%rip)

compiles	to (x86-32)

In fpstack this compiles esp eax movl esp	fildl (%esp) fmuls LCPI1_0 addl $4

In fpstack this compiles esp eax movl esp esp ret in SSE it compiles into significantly slower esp	cvtsi2sd (%esp)

In fpstack this compiles esp eax movl esp esp ret in SSE it compiles into significantly slower esp xmm0 mulsd xmm0 movsd esp	fldl (%esp) addl $12

< float * > store float float *tmp5 ret void Compiles rax rax movl rdi ret This would be better kept in the SSE unit by treating XMM0 as a and doing a shuffle from v[1] to v[0] then a float store[UNSAFE FP] void	foo (double, double, double)

void	norm (double x, double y, double z)

Variables
SSE Variable shift can be custom lowered to something like	this

SSE Variable shift can be custom lowered to something like which uses a small table unaligned load shuffle instead of going through memory	__m128i_shift_right

SSE Variable shift can be custom lowered to something like which uses a small table unaligned load shuffle instead of going through memory	byte

SSE has instructions for doing operations on complex	numbers

SSE has instructions for doing operations on complex we should pattern match them For	example

SSE has instructions for doing operations on complex we should pattern match them For this should turn into a horizontal	add

Instead we get	xmm0

Instead we get xmm1 addss xmm1	pshufd

Instead we get xmm1 addss xmm1 xmm2 movhlps xmm0 movaps xmm3 addss	xmm1

Instead we get xmm1 addss xmm1 xmm2 movhlps xmm0 movaps xmm3 addss xmm3 movdqa	xmm2

Instead we get xmm1 addss xmm1 xmm2 movhlps xmm0 movaps xmm3 addss xmm3 movdqa xmm0 addss	xmm3

Instead we get xmm1 addss xmm1 xmm2 movhlps xmm0 movaps xmm3 addss xmm3 movdqa xmm0 addss xmm0 ret	Also

Instead we get xmm1 addss xmm1 xmm2 movhlps xmm0 movaps xmm3 addss xmm3 movdqa xmm0 addss xmm0 ret there are cases where some simple SLP would improve codegen a bit compiling _Complex float	B

into	__pad1__

into xmm2 addss xmm2 xmm1 xmm3 addss xmm3 movaps xmm0 unpcklps xmm0 ret seems silly when it could just be one addps Expand libm rounding functions	inline

into xmm2 addss xmm2 xmm1 xmm3 addss xmm3 movaps xmm0 unpcklps xmm0 ret seems silly when it could just be one addps Expand libm rounding functions main should enable SSE DAZ mode and other fast SSE modes Think about doing i64 math in SSE regs on x86 This testcase should have no SSE instructions in	it

into xmm2 addss xmm2 xmm1 xmm3 addss xmm3 movaps xmm0 unpcklps xmm0 ret seems silly when it could just be one addps Expand libm rounding functions main should enable SSE DAZ mode and other fast SSE modes Think about doing i64 math in SSE regs on x86 This testcase should have no SSE instructions in and only one load from a constant	pool

into xmm2 addss xmm2 xmm1 xmm3 addss xmm3 movaps xmm0 unpcklps xmm0 ret seems silly when it could just be one addps Expand libm rounding functions main should enable SSE DAZ mode and other fast SSE modes Think about doing i64 math in SSE regs on x86 This testcase should have no SSE instructions in and only one load from a constant	double

into xmm2 addss xmm2 xmm1 xmm3 addss xmm3 movaps xmm0 unpcklps xmm0 ret seems silly when it could just be one addps Expand libm rounding functions main should enable SSE DAZ mode and other fast SSE modes Think about doing i64 math in SSE regs on x86 This testcase should have no SSE instructions in and only one load from a constant double ret double C	Currently

into xmm2 addss xmm2 xmm1 xmm3 addss xmm3 movaps xmm0 unpcklps xmm0 ret seems silly when it could just be one addps Expand libm rounding functions main should enable SSE DAZ mode and other fast SSE modes Think about doing i64 math in SSE regs on x86 This testcase should have no SSE instructions in and only one load from a constant double ret double C the select is being	lowered

This compiles	into

This compiles xmm1 mulss xmm1 xorps xmm0 movss xmm0 ret Because mulss doesn t modify the top	elements

This compiles xmm1 mulss xmm1 xorps xmm0 movss xmm0 ret Because mulss doesn t modify the top the top elements of xmm1 are already zero d We could compile this	to

This might compile to this	code

This might compile to this xmm1 xorps xmm0 movss xmm0 ret Now consider if the code caused xmm1 to get spilled This might produce this xmm1 movaps xmm0 movaps xmm1 movss xmm0 ret	However

This might compile to this xmm1 xorps xmm0 movss xmm0 ret Now consider if the code caused xmm1 to get spilled This might produce this xmm1 movaps xmm0 movaps xmm1 movss xmm0 ret since the reload is only used by these	instructions

This might compile to this xmm1 xorps xmm0 movss xmm0 ret Now consider if the code caused xmm1 to get spilled This might produce this xmm1 movaps xmm0 movaps xmm1 movss xmm0 ret since the reload is only used by these we could fold it into the	uses

This might compile to this xmm1 xorps xmm0 movss xmm0 ret Now consider if the code caused xmm1 to get spilled This might produce this xmm1 movaps xmm0 movaps xmm1 movss xmm0 ret since the reload is only used by these we could fold it into the producing something like xmm1 movaps xmm0 ret saving two instructions The basic idea is that a reload from a spill	slot

This might compile to this xmm1 xorps xmm0 movss xmm0 ret Now consider if the code caused xmm1 to get spilled This might produce this xmm1 movaps xmm0 movaps xmm1 movss xmm0 ret since the reload is only used by these we could fold it into the producing something like xmm1 movaps xmm0 ret saving two instructions The basic idea is that a reload from a spill	can

This might compile to this xmm1 xorps xmm0 movss xmm0 ret Now consider if the code caused xmm1 to get spilled This might produce this xmm1 movaps xmm0 movaps xmm1 movss xmm0 ret since the reload is only used by these we could fold it into the producing something like xmm1 movaps xmm0 ret saving two instructions The basic idea is that a reload from a spill if only one byte chunk is	used

This might compile to this xmm1 xorps xmm0 movss xmm0 ret Now consider if the code caused xmm1 to get spilled This might produce this xmm1 movaps xmm0 movaps xmm1 movss xmm0 ret since the reload is only used by these we could fold it into the producing something like xmm1 movaps xmm0 ret saving two instructions The basic idea is that a reload from a spill if only one byte chunk is bring in zeros the one element instead of elements This can be used to simplify a variety of shuffle	operations

This might compile to this xmm1 xorps xmm0 movss xmm0 ret Now consider if the code caused xmm1 to get spilled This might produce this xmm1 movaps xmm0 movaps xmm1 movss xmm0 ret since the reload is only used by these we could fold it into the producing something like xmm1 movaps xmm0 ret saving two instructions The basic idea is that a reload from a spill if only one byte chunk is bring in zeros the one element instead of elements This can be used to simplify a variety of shuffle where the elements are fixed zeros This code generates ugly probably due to costs being off or	something

This might compile to this xmm1 xorps xmm0 movss xmm0 ret Now consider if the code caused xmm1 to get spilled This might produce this xmm1 movaps xmm0 movaps xmm1 movss xmm0 ret since the reload is only used by these we could fold it into the producing something like xmm1 movaps xmm0 ret saving two instructions The basic idea is that a reload from a spill if only one byte chunk is bring in zeros the one element instead of elements This can be used to simplify a variety of shuffle where the elements are fixed zeros This code generates ugly probably due to costs being off or< 4 x float > *	P2

This might compile to this xmm1 xorps xmm0 movss xmm0 ret Now consider if the code caused xmm1 to get spilled This might produce this xmm1 movaps xmm0 movaps xmm1 movss xmm0 ret since the reload is only used by these we could fold it into the producing something like xmm1 movaps xmm0 ret saving two instructions The basic idea is that a reload from a spill if only one byte chunk is bring in zeros the one element instead of elements This can be used to simplify a variety of shuffle where the elements are fixed zeros This code generates ugly probably due to costs being off or< 4 x float > eax xmm0 pxor xmm1 movaps xmm2	shufps

This might compile to this xmm1 xorps xmm0 movss xmm0 ret Now consider if the code caused xmm1 to get spilled This might produce this xmm1 movaps xmm0 movaps xmm1 movss xmm0 ret since the reload is only used by these we could fold it into the producing something like xmm1 movaps xmm0 ret saving two instructions The basic idea is that a reload from a spill if only one byte chunk is bring in zeros the one element instead of elements This can be used to simplify a variety of shuffle where the elements are fixed zeros This code generates ugly probably due to costs being off or< 4 x float > eax xmm0 pxor xmm1 movaps xmm2 xmm2 xmm0 movaps eax ret Would it be better to	generate

This might compile to this xmm1 xorps xmm0 movss xmm0 ret Now consider if the code caused xmm1 to get spilled This might produce this xmm1 movaps xmm0 movaps xmm1 movss xmm0 ret since the reload is only used by these we could fold it into the producing something like xmm1 movaps xmm0 ret saving two instructions The basic idea is that a reload from a spill if only one byte chunk is bring in zeros the one element instead of elements This can be used to simplify a variety of shuffle where the elements are fixed zeros This code generates ugly probably due to costs being off or< 4 x float > eax xmm0 pxor xmm1 movaps xmm2 xmm2 xmm0 movaps eax ret Would it be better to ecx xmm0 xor	eax

This might compile to this xmm1 xorps xmm0 movss xmm0 ret Now consider if the code caused xmm1 to get spilled This might produce this xmm1 movaps xmm0 movaps xmm1 movss xmm0 ret since the reload is only used by these we could fold it into the producing something like xmm1 movaps xmm0 ret saving two instructions The basic idea is that a reload from a spill if only one byte chunk is bring in zeros the one element instead of elements This can be used to simplify a variety of shuffle where the elements are fixed zeros This code generates ugly probably due to costs being off or< 4 x float > eax xmm0 pxor xmm1 movaps xmm2 xmm2 xmm0 movaps eax ret Would it be better to ecx xmm0 xor eax	pinsrw

This might compile to this xmm1 xorps xmm0 movss xmm0 ret Now consider if the code caused xmm1 to get spilled This might produce this xmm1 movaps xmm0 movaps xmm1 movss xmm0 ret since the reload is only used by these we could fold it into the producing something like xmm1 movaps xmm0 ret saving two instructions The basic idea is that a reload from a spill if only one byte chunk is bring in zeros the one element instead of elements This can be used to simplify a variety of shuffle where the elements are fixed zeros This code generates ugly probably due to costs being off or< 4 x float > eax xmm0 pxor xmm1 movaps xmm2 xmm2 xmm0 movaps eax ret Would it be better to ecx xmm0 xor eax xmm0 xmm0 movaps ecx ret Some useful information in the Apple Altivec SSE Migration	Guide

This might compile to this xmm1 xorps xmm0 movss xmm0 ret Now consider if the code caused xmm1 to get spilled This might produce this xmm1 movaps xmm0 movaps xmm1 movss xmm0 ret since the reload is only used by these we could fold it into the producing something like xmm1 movaps xmm0 ret saving two instructions The basic idea is that a reload from a spill if only one byte chunk is bring in zeros the one element instead of elements This can be used to simplify a variety of shuffle where the elements are fixed zeros This code generates ugly probably due to costs being off or< 4 x float > eax xmm0 pxor xmm1 movaps xmm2 xmm2 xmm0 movaps eax ret Would it be better to ecx xmm0 xor eax xmm0 xmm0 movaps ecx ret Some useful information in the Apple Altivec SSE Migration	andnot

This might compile to this xmm1 xorps xmm0 movss xmm0 ret Now consider if the code caused xmm1 to get spilled This might produce this xmm1 movaps xmm0 movaps xmm1 movss xmm0 ret since the reload is only used by these we could fold it into the producing something like xmm1 movaps xmm0 ret saving two instructions The basic idea is that a reload from a spill if only one byte chunk is bring in zeros the one element instead of elements This can be used to simplify a variety of shuffle where the elements are fixed zeros This code generates ugly probably due to costs being off or< 4 x float > eax xmm0 pxor xmm1 movaps xmm2 xmm2 xmm0 movaps eax ret Would it be better to ecx xmm0 xor eax xmm0 xmm0 movaps ecx ret Some useful information in the Apple Altivec SSE Migration or Various SSE compare translations Add hooks to commute some CMPP operations Apply the same transformation that merged four float into a single bit load to loads from constant pool Floating point max min are commutable when enable unsafe fp path is specified We should turn int_x86_sse_max_ss and X86ISD::FMIN etc into other nodes which are selected to max min instructions that are marked commutable We should materialize vector constants like all ones and signbit with code	like

This currently compiles esp xmm0 movsd esp eax	shrl

This currently compiles esp xmm0 movsd esp eax eax	addl

This currently compiles esp xmm0 movsd esp eax eax esp ret We should use	movmskp

This currently compiles esp xmm0 movsd esp eax eax esp ret We should use not the dag combiner This is because dagcombine2 needs to be able to see through the X86ISD::Wrapper	node

This currently compiles esp xmm0 movsd esp eax eax esp ret We should use not the dag combiner This is because dagcombine2 needs to be able to see through the X86ISD::Wrapper which DAGCombine can t really do The code for turning x load into a single vector load is target independent and should be moved to the dag combiner The code for turning x load into a vector load can only handle a direct load from a global or a direct load from the stack It should be generalized to handle any load from	P

This currently compiles esp xmm0 movsd esp eax eax esp ret We should use not the dag combiner This is because dagcombine2 needs to be able to see through the X86ISD::Wrapper which DAGCombine can t really do The code for turning x load into a single vector load is target independent and should be moved to the dag combiner The code for turning x load into a vector load can only handle a direct load from a global or a direct load from the stack It should be generalized to handle any load from where P can be anything The alignment inference code cannot handle loads from globals in static non mode because it doesn t look through the extra dyld stub load If you try vec_align ll without relocation	model =static

This currently compiles esp xmm0 movsd esp eax eax esp ret We should use not the dag combiner This is because dagcombine2 needs to be able to see through the X86ISD::Wrapper which DAGCombine can t really do The code for turning x load into a single vector load is target independent and should be moved to the dag combiner The code for turning x load into a vector load can only handle a direct load from a global or a direct load from the stack It should be generalized to handle any load from where P can be anything The alignment inference code cannot handle loads from globals in static non mode because it doesn t look through the extra dyld stub load If you try vec_align ll without relocation you ll see what I mean We should lower which eliminates a constant pool load For	consider

This currently compiles esp xmm0 movsd esp eax eax esp ret We should use not the dag combiner This is because dagcombine2 needs to be able to see through the X86ISD::Wrapper which DAGCombine can t really do The code for turning x load into a single vector load is target independent and should be moved to the dag combiner The code for turning x load into a vector load can only handle a direct load from a global or a direct load from the stack It should be generalized to handle any load from where P can be anything The alignment inference code cannot handle loads from globals in static non mode because it doesn t look through the extra dyld stub load If you try vec_align ll without relocation you ll see what I mean We should lower which eliminates a constant pool load For float z nounwind	readonly

< float >	tmp20

the custom lowered code happens to be	right

the custom lowered code happens to be but we shouldn t have to custom lower anything This is probably related to< 2 x i64 > ops being so bad LLVM currently generates stack realignment when it is not necessary needed The problem is that we need to know about stack alignment too	early

the custom lowered code happens to be but we shouldn t have to custom lower anything This is probably related to< 2 x i64 > ops being so bad LLVM currently generates stack realignment when it is not necessary needed The problem is that we need to know about stack alignment too before RA runs At that point we don t	know

the custom lowered code happens to be but we shouldn t have to custom lower anything This is probably related to< 2 x i64 > ops being so bad LLVM currently generates stack realignment when it is not necessary needed The problem is that we need to know about stack alignment too before RA runs At that point we don t whether there will be vector	spill

the custom lowered code happens to be but we shouldn t have to custom lower anything This is probably related to< 2 x i64 > ops being so bad LLVM currently generates stack realignment when it is not necessary needed The problem is that we need to know about stack alignment too before RA runs At that point we don t whether there will be vector or not Stack realignment logic is overly conservative	here

the custom lowered code happens to be but we shouldn t have to custom lower anything This is probably related to< 2 x i64 > ops being so bad LLVM currently generates stack realignment when it is not necessary needed The problem is that we need to know about stack alignment too before RA runs At that point we don t whether there will be vector or not Stack realignment logic is overly conservative but otherwise we can produce unaligned loads stores Fixing this will require some huge RA changes	Testcase

static const vSInt16	a

In x86	mode

In x86 we generate this spiffy xmm0 xmm0 ret in x86 we generate this which could be	better

In x86 we generate this spiffy xmm0 xmm0 ret in x86 we generate this which could be xmm1 movss xmm1 xmm0 ret In sse4 we could use insertps to make both better Here s another testcase that could use	insertps [mem]

In x86 we generate this spiffy xmm0 xmm0 ret in x86 we generate this which could be xmm1 movss xmm1 xmm0 ret In sse4 we could use insertps to make both better Here s another testcase that could use	x3

gcc mainline compiles it xmm0 xmm1 movaps xmm2 movlhps xmm2 movaps xmm0 ret We compile vector multiply by constant into poor< i32 10, i32 10, i32 10, i32 10 > ret< 4 x i32 > A On targets without	SSE4

gcc mainline compiles it xmm0 xmm1 movaps xmm2 movlhps xmm2 movaps xmm0 ret We compile vector multiply by constant into poor< i32 10, i32 10, i32 10, i32 10 > ret< 4 x i32 > A On targets without this compiles globl _f	_f

gcc mainline compiles it xmm0 xmm1 movaps xmm2 movlhps xmm2 movaps xmm0 ret We compile vector multiply by constant into poor< i32 10, i32 10, i32 10, i32 10 > ret< 4 x i32 > A On targets without this compiles globl _f xmm1 movd eax imull	LCPI1_0

into	__pad2__

into eax xorps xmm0 xmm0 eax xmm0	movl

into eax xorps xmm0 xmm0 eax xmm0 eax xmm0 ret	gcc

into eax xorps xmm0 xmm0 eax xmm0 eax xmm0 ret esp eax movdqa	LC0

into eax xorps xmm0 xmm0 eax xmm0 eax xmm0 ret esp eax movdqa xmm0 xmm0 esp const ret align it should be movdqa xmm0	pinsrb

into eax xorps xmm0 xmm0 eax xmm0 eax xmm0 ret esp eax movdqa xmm0 xmm0 esp const ret align it should be movdqa xmm0	edi

into eax xorps xmm0 xmm0 eax xmm0 eax xmm0 ret esp eax movdqa xmm0 xmm0 esp const ret align it should be movdqa xmm0 xmm0 We should transform a shuffle of two vectors of constants into a single vector of constants insertelement of a constant into a vector of constants should also result in a vector of constants e g VecISelBug ll We compiled it to something	horrible

into eax xorps xmm0 xmm0 eax xmm0 eax xmm0 ret esp eax movdqa xmm0 xmm0 esp const ret align it should be movdqa xmm0 xmm0 We should transform a shuffle of two vectors of constants into a single vector of constants insertelement of a constant into a vector of constants should also result in a vector of constants e g VecISelBug ll We compiled it to something globl _t	_t

into eax xorps xmm0 xmm0 eax xmm0 eax xmm0 ret esp eax movdqa xmm0 xmm0 esp const ret align it should be movdqa xmm0 xmm0 We should transform a shuffle of two vectors of constants into a single vector of constants insertelement of a constant into a vector of constants should also result in a vector of constants e g VecISelBug ll We compiled it to something globl _t xmm0 movhps xmm0 movss	LCPI1_1

into eax xorps xmm0 xmm0 eax xmm0 eax xmm0 ret esp eax movdqa xmm0 xmm0 esp const ret align it should be movdqa xmm0 xmm0 We should transform a shuffle of two vectors of constants into a single vector of constants insertelement of a constant into a vector of constants should also result in a vector of constants e g VecISelBug ll We compiled it to something globl _t xmm0 movhps xmm0 movss xmm1 movaps xmm2 xmm2 xmm0 movaps	rdar

< double >	tmp19 = bitcast double %tmp18 to i64

< i128 >	tmp10 = lshr i128 %tmp20

< i128 >< i128 >	tmp11 = trunc i128 %tmp10 to i32

< i32 >	tmp12 = bitcast i32 %tmp11 to float

< float >	tmp5 = getelementptr inbounds %struct.float3* %res

< float >	i64

< float >	i32

< float * > store float float *tmp5 ret void Compiles rax	shrq

We currently generate an sqrtsd and divsd instructions This is	bad

We currently generate an sqrtsd and divsd instructions This is fp div is slow and not pipelined In ffast math mode we could compute scale first and emit mulsd in place of the divs This can be done as a target independent transform If we re dealing with floats instead of doubles we could even replace the sqrtss and inversion with an rsqrtss	instruction

Typedef Documentation

◆ t

using t = bitcast float %x to i32 %s = and i32 %t, 2147483647 %d = bitcast i32 %s to float ret float %d } declare float @fabsf(float %n) define float @bar(float %x) nounwind { %d = call float @fabsf(float %x) ret float %d } This IR (from PR6194): target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64-S128" target triple = "x86_64-apple-darwin10.0.0" %0 = type { double, double } %struct.float3 = type { float, float, float } define void @test(%0, %struct.float3* nocapture %res) nounwind noinline ssp { entry: %tmp18 = extractvalue %0 %0, 0

Definition at line 788 of file README-SSE.txt.

Function Documentation

◆ _mm_set_ps()

return _mm_set_ps	(	0.	0,
		0.	0,
		0.	0,
		b
	)

Referenced by foo1().

◆ c2()

This might compile to this xmm1 xorps xmm0 movss xmm0 ret Now consider if the code caused xmm1 to get spilled This might produce this xmm1 movaps xmm0 movaps xmm1 movss xmm0 ret since the reload is only used by these we could fold it into the producing something like xmm1 movaps c2 ( % esp )

Referenced by categorize(), samesets(), and llvm::setProfMetadata().

◆ code()

Generated code	(	x86-	32,
		linux
	)

Definition at line 508 of file README-SSE.txt.

◆ cvtsi2sd()

In fpstack this compiles esp eax movl esp esp ret in SSE it compiles into significantly slower esp cvtsi2sd ( % esp )

◆ f32()

float f32 ( v4f32 A )

Definition at line 26 of file README-SSE.txt.

References A.

◆ fildl()

In fpstack this compiles esp eax movl esp fildl ( % esp )

◆ fldl()

In fpstack this compiles esp eax movl esp esp ret in SSE it compiles into significantly slower esp xmm0 mulsd xmm0 movsd esp fldl ( % esp )

◆ foo()

<float> store float float tmp5 ret void Compiles rax rax movl rdi ret This would be better kept in the SSE unit by treating XMM0 as a and doing a shuffle from v [1] to v [0] then a float store [UNSAFE FP] void foo	(	double	,
		double	,
		double
	)

Referenced by norm().

◆ foo1()

__m128 foo1	(	float	x1,
		float	x4
	)

Definition at line 548 of file README-SSE.txt.

References _mm_set_ps(), x2(), and x3.

◆ LC0()

into eax xorps xmm0 xmm0 eax xmm0 eax xmm0 ret esp eax movdqa xmm0 xmm0 esp const ret align it should be movdqa LC0 ( % rip )

◆ load()

into xmm2 addss xmm2 xmm1 xmm3 addss xmm3 movaps xmm0 unpcklps xmm0 ret seems silly when it could just be one addps Expand libm rounding functions main should enable SSE DAZ mode and other fast SSE modes Think about doing i64 math in SSE regs on x86 This testcase should have no SSE instructions in and only one load from a constant double ret double C the select is being which prevents the dag combiner from turning load CPI2 load	(	select	CPI1,
		CPI2
	)

Definition at line 90 of file README-SSE.txt.

◆ madd()

vSInt16 madd ( vSInt16 b )

Definition at line 503 of file README-SSE.txt.

◆ movaps()

_test eax xmm0 eax movaps ( % eax )

◆ movl()

This currently compiles esp xmm0 movsd esp movl ( % esp )

◆ movsd()

This currently compiles esp movsd ( % esp )

◆ movzbl()

into eax xorps xmm0 xmm0 movzbl ( % esp )

◆ norm()

void norm	(	double	x,
		double	y,
		double	z
	)

Definition at line 815 of file README-SSE.txt.

References foo(), scale(), x(), y(), and z.

◆ select()

into xmm2 addss xmm2 xmm1 xmm3 addss xmm3 movaps xmm0 unpcklps xmm0 ret seems silly when it could just be one addps Expand libm rounding functions main should enable SSE DAZ mode and other fast SSE modes Think about doing i64 math in SSE regs on x86 This testcase should have no SSE instructions in and only one load from a constant double ret double C the select is being which prevents the dag combiner from turning select ( load CPI1 )

Referenced by zero().

◆ shift_right()

SSE Variable shift can be custom lowered to something like which uses a small table unaligned load shuffle instead of going through memory __m128i shift_right	(	__m128i	value,
		unsigned long	offset
	)

Definition at line 15 of file README-SSE.txt.

◆ store()

This currently compiles esp xmm0 movsd esp eax eax esp ret We should use not the dag combiner This is because dagcombine2 needs to be able to see through the X86ISD::Wrapper which DAGCombine can t really do The code for turning x load into a single vector load is target independent and should be moved to the dag combiner The code for turning x load into a vector load can only handle a direct load from a global or a direct load from the stack It should be generalized to handle any load from where P can be anything The alignment inference code cannot handle loads from globals in static non mode because it doesn t look through the extra dyld stub load If you try vec_align ll without relocation you ll see what I mean We should lower store	(	fneg(load p)	,
		q
	)

static

◆ to() [1/2]

compile to ( -O3 -static -fomit-frame- pointer )

Definition at line 362 of file README-SSE.txt.

References d.

◆ to() [2/2]

compiles to ( x86- 32 )

Definition at line 692 of file README-SSE.txt.

References i8, ret(), tmp12, to, uses, and x().

◆ x()

void x ( unsigned short n )

Definition at line 355 of file README-SSE.txt.

References n.

Referenced by norm(), and to().

◆ x2()

gcc mainline compiles it x2 ( % rip )

Referenced by llvm::DecodeVPERMIL2PMask(), foo1(), getDecodedGVarFlags(), llvm::X86InstrInfo::getExecutionDomainCustom(), getMClassFlagsMask(), parseTexFail(), llvm::ModuleSummaryIndex::setFlags(), and llvm::X86TTIImpl::simplifyDemandedVectorEltsIntrinsic().

◆ x3()

gcc mainline compiles it xmm0 x3 ( % rip )

◆ y()

void y ( unsigned n )

Definition at line 358 of file README-SSE.txt.

References n.

Referenced by norm().

Variable Documentation

◆ __m128i_shift_right

SSE Variable shift can be custom lowered to something like which uses a small table unaligned load shuffle instead of going through memory __m128i_shift_right

Definition at line 11 of file README-SSE.txt.

◆ pad1

into __pad1__

Definition at line 53 of file README-SSE.txt.

◆ pad2

into __pad2__

Definition at line 619 of file README-SSE.txt.

◆ _f

gcc mainline compiles it xmm0 xmm1 movaps xmm2 movlhps xmm2 movaps xmm0 ret We compile vector multiply by constant into poor< i32 10, i32 10, i32 10, i32 10 > ret<4 x i32> A On targets without this compiles globl _f _f

Definition at line 582 of file README-SSE.txt.

◆ _t

into eax xorps xmm0 xmm0 eax xmm0 eax xmm0 ret esp eax movdqa xmm0 xmm0 esp const ret align it should be movdqa xmm0 xmm0 We should transform a shuffle of two vectors of constants into a single vector of constants insertelement of a constant into a vector of constants should also result in a vector of constants e g VecISelBug ll We compiled it to something globl _t _t

Definition at line 675 of file README-SSE.txt.

◆ a

const vSInt16 a

static

Initial value:

= {- 22725, - 12873, - 22725, - 12873, - 22725, - 12873,

- 22725, - 12873}

Definition at line 500 of file README-SSE.txt.

◆ add

Current eax eax eax ret Ideal eax eax ret Re implement atomic builtins x86 does not have to use add to implement these it can use add

Definition at line 25 of file README-SSE.txt.

◆ addl

into eax xorps xmm0 xmm0 eax xmm0 eax xmm0 ret esp eax movdqa xmm0 xmm0 addl

Definition at line 394 of file README-SSE.txt.

◆ Also

into eax xorps xmm0 xmm0 eax xmm0 eax xmm0 ret esp eax movdqa xmm0 xmm0 esp const ret align it should be movdqa xmm0 xmm0 We should transform a shuffle of two vectors of constants into a single vector of constants Also

Definition at line 43 of file README-SSE.txt.

◆ andnot

This might compile to this xmm1 xorps xmm0 movss xmm0 ret Now consider if the code caused xmm1 to get spilled This might produce this xmm1 movaps xmm0 movaps xmm1 movss xmm0 ret since the reload is only used by these we could fold it into the producing something like xmm1 movaps xmm0 ret saving two instructions The basic idea is that a reload from a spill if only one byte chunk is bring in zeros the one element instead of elements This can be used to simplify a variety of shuffle where the elements are fixed zeros This code generates ugly probably due to costs being off or<4 x float> eax xmm0 pxor xmm1 movaps xmm2 xmm2 xmm0 movaps eax ret Would it be better to ecx xmm0 xor eax xmm0 xmm0 movaps ecx ret Some useful information in the Apple Altivec SSE Migration andnot

Definition at line 318 of file README-SSE.txt.

◆ B

Instead we get xmm1 addss xmm1 xmm2 movhlps xmm0 movaps xmm3 addss xmm3 movdqa xmm0 addss xmm0 ret there are cases where some simple SLP would improve codegen a bit compiling _Complex float B

Initial value:

{

return A+B

Definition at line 46 of file README-SSE.txt.

◆ bad

We currently generate an sqrtsd and divsd instructions This is bad

Definition at line 820 of file README-SSE.txt.

◆ better

In x86 we generate this spiffy xmm0 xmm0 ret in x86 we generate this which could be better

Definition at line 537 of file README-SSE.txt.

◆ byte

Decimal Convert From to National Zoned Signed int_ppc_altivec_bcdcfno int_ppc_altivec_bcdcfzo int_ppc_altivec_bcdctno int_ppc_altivec_bcdctzo int_ppc_altivec_bcdcfsqo int_ppc_altivec_bcdctsqo int_ppc_altivec_bcdcpsgno int_ppc_altivec_bcdsetsgno int_ppc_altivec_bcdso int_ppc_altivec_bcduso int_ppc_altivec_bcdsro i e VA byte

Definition at line 11 of file README-SSE.txt.

Referenced by readPrefixes().

◆ can

This might compile to this xmm1 xorps xmm0 movss xmm0 ret Now consider if the code caused xmm1 to get spilled This might produce this xmm1 movaps xmm0 movaps xmm1 movss xmm0 ret since the reload is only used by these we could fold it into the producing something like xmm1 movaps xmm0 ret saving two instructions The basic idea is that a reload from a spill can

Definition at line 269 of file README-SSE.txt.

◆ code

In fpstack this compiles esp eax movl esp esp ret in SSE it compiles into significantly slower code

Definition at line 240 of file README-SSE.txt.

◆ consider

This currently compiles esp xmm0 movsd esp eax eax esp ret We should use not the dag combiner This is because dagcombine2 needs to be able to see through the X86ISD::Wrapper which DAGCombine can t really do The code for turning x load into a single vector load is target independent and should be moved to the dag combiner The code for turning x load into a vector load can only handle a direct load from a global or a direct load from the stack It should be generalized to handle any load from where P can be anything The alignment inference code cannot handle loads from globals in static non mode because it doesn t look through the extra dyld stub load If you try vec_align ll without relocation you ll see what I mean We should lower which eliminates a constant pool load For consider

Definition at line 421 of file README-SSE.txt.

◆ Currently

into xmm2 addss xmm2 xmm1 xmm3 addss xmm3 movaps xmm0 unpcklps xmm0 ret seems silly when it could just be one addps Expand libm rounding functions main should enable SSE DAZ mode and other fast SSE modes Think about doing i64 math in SSE regs on x86 This testcase should have no SSE instructions in and only one load from a constant double ret double C Currently

Definition at line 89 of file README-SSE.txt.

◆ double

into xmm2 addss xmm2 xmm1 xmm3 addss xmm3 movaps xmm0 unpcklps xmm0 ret seems silly when it could just be one addps Expand libm rounding functions main should enable SSE DAZ mode and other fast SSE modes Think about doing i64 math in SSE regs on x86 This testcase should have no SSE instructions in and only one load from a constant double

Definition at line 85 of file README-SSE.txt.

Referenced by areRuntimeChecksProfitable(), llvm::ExecutionEngine::getConstantValue(), llvm::DOTGraphTraits< DOTFuncInfo * >::getEdgeAttributes(), initBranchWeights(), LowerFPToInt(), llvm::mca::ResourceCycles::operator double(), llvm::mca::IncrementalSourceMgr::printStatistic(), llvm::msgpack::Reader::read(), llvm::APInt::roundToDouble(), llvm::MCJIT::runFunction(), and llvm::Module::setPartialSampleProfileRatio().

◆ early

the custom lowered code happens to be but we shouldn t have to custom lower anything This is probably related to<2 x i64> ops being so bad LLVM currently generates stack realignment when it is not necessary needed The problem is that we need to know about stack alignment too early

Definition at line 486 of file README-SSE.txt.

◆ eax

<float*> store float float* tmp5 ret void Compiles rax rax movl eax

Definition at line 303 of file README-SSE.txt.

◆ edi

into eax xorps xmm0 xmm0 eax xmm0 eax xmm0 ret esp eax movdqa xmm0 xmm0 esp const ret align it should be movdqa xmm0 edi

Definition at line 650 of file README-SSE.txt.

◆ elements

This compiles xmm1 mulss xmm1 xorps xmm0 movss xmm0 ret Because mulss doesn t modify the top elements

Definition at line 221 of file README-SSE.txt.

Referenced by llvm::RegionBase< RegionTraits< Function > >::addSubRegion(), and llvm::RegionBase< RegionTraits< Function > >::print().

◆ example

This currently compiles esp xmm0 movsd esp eax eax esp ret We should use not the dag combiner This is because dagcombine2 needs to be able to see through the X86ISD::Wrapper which DAGCombine can t really do The code for turning x load into a single vector load is target independent and should be moved to the dag combiner The code for turning x load into a vector load can only handle a direct load from a global or a direct load from the stack It should be generalized to handle any load from where P can be anything The alignment inference code cannot handle loads from globals in static non mode because it doesn t look through the extra dyld stub load If you try vec_align ll without relocation you ll see what I mean We should lower which eliminates a constant pool load For example

Definition at line 23 of file README-SSE.txt.

◆ gcc

into eax xorps xmm0 xmm0 eax xmm0 eax xmm0 ret gcc

Definition at line 630 of file README-SSE.txt.

◆ generate

This might compile to this xmm1 xorps xmm0 movss xmm0 ret Now consider if the code caused xmm1 to get spilled This might produce this xmm1 movaps xmm0 movaps xmm1 movss xmm0 ret since the reload is only used by these we could fold it into the producing something like xmm1 movaps xmm0 ret saving two instructions The basic idea is that a reload from a spill if only one byte chunk is bring in zeros the one element instead of elements This can be used to simplify a variety of shuffle where the elements are fixed zeros This code generates ugly probably due to costs being off or<4 x float> eax xmm0 pxor xmm1 movaps xmm2 xmm2 xmm0 movaps eax ret Would it be better to generate

Definition at line 301 of file README-SSE.txt.

◆ Guide

This might compile to this xmm1 xorps xmm0 movss xmm0 ret Now consider if the code caused xmm1 to get spilled This might produce this xmm1 movaps xmm0 movaps xmm1 movss xmm0 ret since the reload is only used by these we could fold it into the producing something like xmm1 movaps xmm0 ret saving two instructions The basic idea is that a reload from a spill if only one byte chunk is bring in zeros the one element instead of elements This can be used to simplify a variety of shuffle where the elements are fixed zeros This code generates ugly probably due to costs being off or<4 x float> eax xmm0 pxor xmm1 movaps xmm2 xmm2 xmm0 movaps eax ret Would it be better to ecx xmm0 xor eax xmm0 xmm0 movaps ecx ret Some useful information in the Apple Altivec SSE Migration Guide

Definition at line 318 of file README-SSE.txt.

◆ here

the custom lowered code happens to be but we shouldn t have to custom lower anything This is probably related to<2 x i64> ops being so bad LLVM currently generates stack realignment when it is not necessary needed The problem is that we need to know about stack alignment too before RA runs At that point we don t whether there will be vector or not Stack realignment logic is overly conservative here

Definition at line 490 of file README-SSE.txt.

◆ horrible

into eax xorps xmm0 xmm0 eax xmm0 eax xmm0 ret esp eax movdqa xmm0 xmm0 esp const ret align it should be movdqa xmm0 xmm0 We should transform a shuffle of two vectors of constants into a single vector of constants insertelement of a constant into a vector of constants should also result in a vector of constants e g VecISelBug ll We compiled it to something horrible

Definition at line 672 of file README-SSE.txt.

◆ However

This might compile to this xmm1 xorps xmm0 movss xmm0 ret Now consider if the code caused xmm1 to get spilled This might produce this xmm1 movaps xmm0 movaps xmm1 movss xmm0 ret However

Definition at line 257 of file README-SSE.txt.

◆ i32

<float> i32

Definition at line 794 of file README-SSE.txt.

◆ i64

<float> i64

Definition at line 794 of file README-SSE.txt.

◆ inline

into xmm2 addss xmm2 xmm1 xmm3 addss xmm3 movaps xmm0 unpcklps xmm0 ret seems silly when it could just be one addps Expand libm rounding functions inline

Definition at line 72 of file README-SSE.txt.

◆ insertps

gcc mainline compiles it xmm0 insertps

Definition at line 547 of file README-SSE.txt.

◆ instruction

We currently generate an sqrtsd and divsd instructions This is fp div is slow and not pipelined In ffast math mode we could compute scale first and emit mulsd in place of the divs This can be done as a target independent transform If we re dealing with floats instead of doubles we could even replace the sqrtss and inversion with an rsqrtss instruction

Definition at line 826 of file README-SSE.txt.

◆ instructions

This might compile to this xmm1 xorps xmm0 movss xmm0 ret Now consider if the code caused xmm1 to get spilled This might produce this xmm1 movaps xmm0 movaps xmm1 movss xmm0 ret since the reload is only used by these instructions

Definition at line 257 of file README-SSE.txt.

◆ into

In fpstack this compiles into

Definition at line 215 of file README-SSE.txt.

◆ it

into xmm2 addss xmm2 xmm1 xmm3 addss xmm3 movaps xmm0 unpcklps xmm0 ret seems silly when it could just be one addps Expand libm rounding functions main should enable SSE DAZ mode and other fast SSE modes Think about doing i64 math in SSE regs on x86 This testcase should have no SSE instructions in it

Definition at line 81 of file README-SSE.txt.

Referenced by llvm::detail::all_of_zip_predicate_first(), llvm::MachObjectWriter::bindIndirectSymbols(), llvm::mca::ResourceManager::checkAvailability(), checkOverlappingElement(), llvm::sys::DynamicLibrary::HandleSet::CloseLibrary(), llvm::MachObjectWriter::computeSymbolTable(), llvm::SMSchedule::cycleScheduled(), dominatesAllUsesOf(), llvm::MCFragment::dump(), llvm::MCSection::dump(), llvm::MCAssembler::dump(), llvm::SMSchedule::earliestCycleInChain(), llvm::AArch64TargetWinCOFFStreamer::emitARM64WinCFIPrologEnd(), llvm::MipsAsmPrinter::emitEndOfAsmFile(), llvm::SampleProfileLoaderBaseImpl< MachineBasicBlock >::findFunctionSamples(), llvm::opt::Arg::getAsString(), llvm::X86FrameLowering::getWin64EHFrameIndexRef(), llvm::StringSet< AllocatorTy >::insert(), llvm::SMSchedule::latestCycleInChain(), llvm::StringMap< uint64_t >::lookup(), LookupNearestOption(), llvm::yaml::MappingTraits< const InterfaceFile * >::NormalizedTBD_V4::NormalizedTBD_V4(), llvm::ARMAsmBackend::setIsThumb(), llvm::SMSchedule::stageScheduled(), and llvm::MachObjectWriter::writeObject().

◆ know

the custom lowered code happens to be but we shouldn t have to custom lower anything This is probably related to<2 x i64> ops being so bad LLVM currently generates stack realignment when it is not necessary needed The problem is that we need to know about stack alignment too before RA runs At that point we don t know

Definition at line 489 of file README-SSE.txt.

◆ LC0

into eax xorps xmm0 xmm0 eax xmm0 eax xmm0 ret esp eax movdqa xmm0 xmm0 esp const ret align LC0

Definition at line 632 of file README-SSE.txt.

Referenced by DecodeCtrRegsRegisterClass(), llvm::HexagonTargetLowering::getRegisterByName(), and llvm::HexagonRegisterInfo::getReservedRegs().

◆ LCPI1_0

In fpstack this compiles esp eax movl esp esp ret in SSE it compiles into significantly slower esp xmm0 mulsd LCPI1_0

Definition at line 584 of file README-SSE.txt.

◆ LCPI1_1

into eax xorps xmm0 xmm0 eax xmm0 eax xmm0 ret esp eax movdqa xmm0 xmm0 esp const ret align it should be movdqa xmm0 xmm0 We should transform a shuffle of two vectors of constants into a single vector of constants insertelement of a constant into a vector of constants should also result in a vector of constants e g VecISelBug ll We compiled it to something globl _t xmm0 movhps xmm0 movss LCPI1_1

Definition at line 677 of file README-SSE.txt.

◆ like

This might compile to this xmm1 xorps xmm0 movss xmm0 ret Now consider if the code caused xmm1 to get spilled This might produce this xmm1 movaps xmm0 movaps xmm1 movss xmm0 ret since the reload is only used by these we could fold it into the producing something like xmm1 movaps xmm0 ret saving two instructions The basic idea is that a reload from a spill if only one byte chunk is bring in zeros the one element instead of elements This can be used to simplify a variety of shuffle where the elements are fixed zeros This code generates ugly probably due to costs being off or<4 x float> eax xmm0 pxor xmm1 movaps xmm2 xmm2 xmm0 movaps eax ret Would it be better to ecx xmm0 xor eax xmm0 xmm0 movaps ecx ret Some useful information in the Apple Altivec SSE Migration or Various SSE compare translations Add hooks to commute some CMPP operations Apply the same transformation that merged four float into a single bit load to loads from constant pool Floating point max min are commutable when enable unsafe fp path is specified We should turn int_x86_sse_max_ss and X86ISD::FMIN etc into other nodes which are selected to max min instructions that are marked commutable We should materialize vector constants like all ones and signbit with code like

Definition at line 340 of file README-SSE.txt.

◆ lowered

into xmm2 addss xmm2 xmm1 xmm3 addss xmm3 movaps xmm0 unpcklps xmm0 ret seems silly when it could just be one addps Expand libm rounding functions main should enable SSE DAZ mode and other fast SSE modes Think about doing i64 math in SSE regs on x86 This testcase should have no SSE instructions in and only one load from a constant double ret double C the select is being lowered

Definition at line 89 of file README-SSE.txt.

◆ mode

In fpstack this compiles esp eax movl esp esp ret in SSE mode

Definition at line 527 of file README-SSE.txt.

◆ model

This currently compiles esp xmm0 movsd esp eax eax esp ret We should use not the dag combiner This is because dagcombine2 needs to be able to see through the X86ISD::Wrapper which DAGCombine can t really do The code for turning x load into a single vector load is target independent and should be moved to the dag combiner The code for turning x load into a vector load can only handle a direct load from a global or a direct load from the stack It should be generalized to handle any load from where P can be anything The alignment inference code cannot handle loads from globals in static non mode because it doesn t look through the extra dyld stub load If you try vec_align ll without relocation model =static

static

Definition at line 414 of file README-SSE.txt.

Referenced by llvm::SparcTargetLowering::LowerGlobalTLSAddress(), and LowerToTLSExecModel().

◆ movl

We currently generate a but we really shouldn eax ecx xorl edx divl ecx movl

Definition at line 624 of file README-SSE.txt.

◆ movmskp

This currently compiles esp xmm0 movsd esp eax eax esp ret We should use movmskp

Initial value:

{s|d} instead.
 
CodeGen/X86/vec_align.ll tests whether we can turn 4 scalar loads into a single
(aligned) vector load.  This functionality has a couple of problems.
 
1. The code to infer alignment from loads of globals is in the X86 backend

Definition at line 397 of file README-SSE.txt.

◆ node

This currently compiles esp xmm0 movsd esp eax eax esp ret We should use not the dag combiner This is because dagcombine2 needs to be able to see through the X86ISD::Wrapper node

Definition at line 406 of file README-SSE.txt.

Referenced by llvm::RNSuccIterator< NodeRef, BlockT, RegionT >::RNSuccIterator().

◆ numbers

SSE has instructions for doing operations on complex numbers

Definition at line 22 of file README-SSE.txt.

◆ operations

This might compile to this xmm1 xorps xmm0 movss xmm0 ret Now consider if the code caused xmm1 to get spilled This might produce this xmm1 movaps xmm0 movaps xmm1 movss xmm0 ret since the reload is only used by these we could fold it into the producing something like xmm1 movaps xmm0 ret saving two instructions The basic idea is that a reload from a spill if only one byte chunk is bring in zeros the one element instead of elements This can be used to simplify a variety of shuffle operations

Definition at line 271 of file README-SSE.txt.

◆ P

This currently compiles esp xmm0 movsd esp eax eax esp ret We should use not the dag combiner This is because dagcombine2 needs to be able to see through the X86ISD::Wrapper which DAGCombine can t really do The code for turning x load into a single vector load is target independent and should be moved to the dag combiner The code for turning x load into a vector load can only handle a direct load from a global or a direct load from the stack It should be generalized to handle any load from P

Examples: /home/buildbot/as-worker-4/publish-doxygen-docs/llvm-project/llvm/include/llvm/Transforms/Utils/Local.h.

Definition at line 411 of file README-SSE.txt.

◆ P2

This might compile to this xmm1 xorps xmm0 movss xmm0 ret Now consider if the code caused xmm1 to get spilled This might produce this xmm1 movaps xmm0 movaps xmm1 movss xmm0 ret since the reload is only used by these we could fold it into the producing something like xmm1 movaps xmm0 ret saving two instructions The basic idea is that a reload from a spill if only one byte chunk is bring in zeros the one element instead of elements This can be used to simplify a variety of shuffle where the elements are fixed zeros This code generates ugly probably due to costs being off or<4 x float> * P2

Initial value:

{
        %xFloat0.688 = load float* %P
        %tmp = load <4 x float>* %P2
        %inFloat3.713 = insertelement <4 x float> %tmp, float 0.0, i32 3
        store <4 x float> %inFloat3.713, <4 x float>* %P2
        ret void
}
 
Generates:
 
_test:
  movl  8(%esp)

Definition at line 278 of file README-SSE.txt.

Referenced by llvm::array_pod_sort_comparator(), ConstantIntSortPredicate(), DecodePredRegsRegisterClass(), llvm::HexagonRegisterInfo::getCallerSavedRegs(), getCompoundOp(), getNextVectorRegister(), llvm::HexagonTargetLowering::getRegisterByName(), isInheritanceKind(), llvm::max(), llvm::ScaledNumbers::multiply64(), node_pair(), llvm::predicatesFoldable(), llvm::detail::IEEEFloat::remainder(), and llvm::PPCInstrInfo::SubsumesPredicate().

◆ pinsrb

into eax xorps xmm0 xmm0 eax xmm0 eax xmm0 ret esp eax movdqa xmm0 xmm0 esp const ret align it should be movdqa xmm0 pinsrb

Definition at line 650 of file README-SSE.txt.

◆ pinsrw

into eax xorps xmm0 xmm0 eax xmm0 eax xmm0 ret esp eax movdqa xmm0 pinsrw

Definition at line 304 of file README-SSE.txt.

◆ pool

into xmm2 addss xmm2 xmm1 xmm3 addss xmm3 movaps xmm0 unpcklps xmm0 ret seems silly when it could just be one addps Expand libm rounding functions main should enable SSE DAZ mode and other fast SSE modes Think about doing i64 math in SSE regs on x86 This testcase should have no SSE instructions in and only one load from a constant pool

Definition at line 85 of file README-SSE.txt.

◆ pshufd

gcc mainline compiles it xmm0 xmm1 movaps xmm2 movlhps xmm2 movaps xmm0 ret We compile vector multiply by constant into poor< i32 10, i32 10, i32 10, i32 10 > ret< 4 x i32 > A On targets without this compiles globl _f xmm1 movd eax imull eax movd xmm1 pshufd

Definition at line 35 of file README-SSE.txt.

◆ rdar

into eax xorps xmm0 xmm0 eax xmm0 eax xmm0 ret esp eax movdqa xmm0 xmm0 esp const ret align it should be movdqa xmm0 xmm0 We should transform a shuffle of two vectors of constants into a single vector of constants insertelement of a constant into a vector of constants should also result in a vector of constants e g VecISelBug ll We compiled it to something globl _t xmm0 movhps xmm0 movss xmm1 movaps xmm2 xmm2 xmm0 movaps rdar

Definition at line 689 of file README-SSE.txt.

◆ readonly

This currently compiles esp xmm0 movsd esp eax eax esp ret We should use not the dag combiner This is because dagcombine2 needs to be able to see through the X86ISD::Wrapper which DAGCombine can t really do The code for turning x load into a single vector load is target independent and should be moved to the dag combiner The code for turning x load into a vector load can only handle a direct load from a global or a direct load from the stack It should be generalized to handle any load from where P can be anything The alignment inference code cannot handle loads from globals in static non mode because it doesn t look through the extra dyld stub load If you try vec_align ll without relocation you ll see what I mean We should lower which eliminates a constant pool load For float z nounwind readonly

Initial value:

{
entry:
 %tmp6 = fsub float -0.000000e+00, %z.1

Definition at line 421 of file README-SSE.txt.

Referenced by llvm::xray::loadProfile(), llvm::xray::loadTraceFile(), and loadYAML().

◆ right

the custom lowered code happens to be right

Definition at line 480 of file README-SSE.txt.

Referenced by BUCompareLatency(), BURRSort(), checkSpecialNodes(), llvm::ImutAVLTree< ImutInfo >::destroy(), llvm::ImutAVLTree< ImutInfo >::getRight(), PerformADDCombineWithOperands(), llvm::InstrProfValueSiteRecord::sortByCount(), and llvm::InstrProfValueSiteRecord::sortByTargetValues().

◆ shrl

Current eax eax eax ret Ideal eax shrl

Definition at line 393 of file README-SSE.txt.

◆ shrq

<float*> store float float* tmp5 ret void Compiles rax shrq

Definition at line 803 of file README-SSE.txt.

◆ shufps

into eax xorps xmm0 xmm0 eax xmm0 eax xmm0 ret esp eax movdqa xmm0 xmm0 esp const ret align it should be movdqa xmm0 xmm0 We should transform a shuffle of two vectors of constants into a single vector of constants insertelement of a constant into a vector of constants should also result in a vector of constants e g VecISelBug ll We compiled it to something globl _t xmm0 movhps xmm0 movss xmm1 movaps xmm2 xmm2 shufps

Definition at line 293 of file README-SSE.txt.

◆ slot

This might compile to this xmm1 xorps xmm0 movss xmm0 ret Now consider if the code caused xmm1 to get spilled This might produce this xmm1 movaps xmm0 movaps xmm1 movss xmm0 ret since the reload is only used by these we could fold it into the producing something like xmm1 movaps xmm0 ret saving two instructions The basic idea is that a reload from a spill slot

Definition at line 269 of file README-SSE.txt.

◆ something

This might compile to this xmm1 xorps xmm0 movss xmm0 ret Now consider if the code caused xmm1 to get spilled This might produce this xmm1 movaps xmm0 movaps xmm1 movss xmm0 ret since the reload is only used by these we could fold it into the producing something like xmm1 movaps xmm0 ret saving two instructions The basic idea is that a reload from a spill if only one byte chunk is bring in zeros the one element instead of elements This can be used to simplify a variety of shuffle where the elements are fixed zeros This code generates ugly probably due to costs being off or something

Definition at line 278 of file README-SSE.txt.

◆ spill

the custom lowered code happens to be but we shouldn t have to custom lower anything This is probably related to<2 x i64> ops being so bad LLVM currently generates stack realignment when it is not necessary needed The problem is that we need to know about stack alignment too before RA runs At that point we don t whether there will be vector spill

Definition at line 489 of file README-SSE.txt.

Referenced by llvm::RegScavenger::scavengeRegister(), and llvm::RegScavenger::scavengeRegisterBackwards().

◆ SSE4

gcc mainline compiles it xmm0 xmm1 movaps xmm2 movlhps xmm2 movaps xmm0 ret We compile vector multiply by constant into poor< i32 10, i32 10, i32 10, i32 10 > ret<4 x i32> A On targets without SSE4

Definition at line 571 of file README-SSE.txt.

◆ Testcase

the custom lowered code happens to be but we shouldn t have to custom lower anything This is probably related to<2 x i64> ops being so bad LLVM currently generates stack realignment when it is not necessary needed The problem is that we need to know about stack alignment too before RA runs At that point we don t whether there will be vector or not Stack realignment logic is overly conservative but otherwise we can produce unaligned loads stores Fixing this will require some huge RA changes Testcase

Definition at line 498 of file README-SSE.txt.

◆ this

This might compile to this xmm1 xorps xmm0 movss xmm0 ret Now consider if the code caused xmm1 to get spilled This might produce this xmm1 movaps xmm0 movaps xmm1 movss xmm0 ret since the reload is only used by these we could fold it into the producing something like this

Definition at line 7 of file README-SSE.txt.

◆ tmp10

<i128> tmp10 = lshr i128 %tmp20

Definition at line 791 of file README-SSE.txt.

◆ tmp11

<i128><i128> tmp11 = trunc i128 %tmp10 to i32

Definition at line 792 of file README-SSE.txt.

◆ tmp12

< float * > store float tmp12 = bitcast i32 %tmp11 to float

Definition at line 793 of file README-SSE.txt.

Referenced by to().

◆ tmp19

<double> tmp19 = bitcast double %tmp18 to i64

Definition at line 789 of file README-SSE.txt.

◆ tmp20

< i64 > tmp20

Definition at line 424 of file README-SSE.txt.

◆ tmp5

<float> tmp5 = getelementptr inbounds %struct.float3* %res

Definition at line 794 of file README-SSE.txt.

Referenced by foo().

◆ to

<float*> store float float* tmp5 ret void Compiles to

Definition at line 224 of file README-SSE.txt.

Referenced by to().

◆ used

This might compile to this xmm1 xorps xmm0 movss xmm0 ret Now consider if the code caused xmm1 to get spilled This might produce this xmm1 movaps xmm0 movaps xmm1 movss xmm0 ret since the reload is only used by these we could fold it into the producing something like xmm1 movaps xmm0 ret saving two instructions The basic idea is that a reload from a spill if only one byte chunk is used

Definition at line 270 of file README-SSE.txt.

Referenced by llvm::ConnectedVNInfoEqClasses::Classify(), llvm::MD5::final(), and llvm::MD5::update().

◆ uses

This might compile to this xmm1 xorps xmm0 movss xmm0 ret Now consider if the code caused xmm1 to get spilled This might produce this xmm1 movaps xmm0 movaps xmm1 movss xmm0 ret since the reload is only used by these we could fold it into the uses

Definition at line 258 of file README-SSE.txt.

Referenced by abort_gzip(), bar(), foo(), llvm::SelectionDAG::getStackArgumentTokenFactor(), llvm::PPCFunctionInfo::setUsesPICBase(), and to().

◆ x3

In x86 we generate this spiffy xmm0 xmm0 ret in x86 we generate this which could be xmm1 movss xmm1 xmm0 ret In sse4 we could use insertps to make both better Here s another testcase that could use x3

Definition at line 547 of file README-SSE.txt.

Referenced by adjustFixupValue(), llvm::jitlink::aarch64::applyFixup(), canonicalizeLaneShuffleWithRepeatedOps(), combineTargetShuffle(), computeFlagsForAddressComputation(), decode(), llvm::RuntimeDyldMachOAArch64::decodeAddend(), decodeL32ROperand(), DecodeRestrictedSPredicateOperand(), DecodeThreeAddrSRegInstruction(), DecodeVLD4DupInstruction(), llvm::RuntimeDyldMachOAArch64::encodeAddend(), llvm::PPCMCExpr::evaluateAsRelocatableImpl(), llvm::ARM_MC::evaluateBranchTarget(), evaluateMemOpAddrForAddrModeT2_i8s4(), llvm::ARM::WinEH::RuntimeFunction::ExceptionInformationRVA(), llvm::ARM::WinEH::RuntimeFunctionARM64::ExceptionInformationRVA(), llvm::ARM::WinEH::RuntimeFunction::Flag(), llvm::ARM::WinEH::RuntimeFunctionARM64::Flag(), foo1(), GeneratePerfectShuffle(), llvm::AArch64SysReg::genericRegisterString(), getMClassFlagsMask(), llvm::X86::getSwappedVCMPImm(), lowerV2X128Shuffle(), llvm::OnDiskChainedHashTable< Info >::OnDiskChainedHashTable(), llvm::ARM::WinEH::RuntimeFunction::PackedUnwindData(), llvm::ARM::WinEH::RuntimeFunctionARM64::PackedUnwindData(), PostOperandDecodeAdjust(), llvm::ARMInstPrinter::printT2AddrModeImm8s4OffsetOperand(), llvm::ARMInstPrinter::printT2AddrModeImm8s4Operand(), llvm::RuntimeDyldCOFFAArch64::processRelocationRef(), llvm::OnDiskChainedHashTable< Info >::readNumBucketsAndEntries(), simplifyX86insertps(), and llvm::ARM::WinEH::StackAdjustment().

◆ xmm0

In fpstack this compiles esp eax movl esp esp ret in SSE it compiles into significantly slower esp xmm0 mulsd xmm0 movsd xmm0

Definition at line 33 of file README-SSE.txt.

◆ xmm1

gets compiled into this on rsp movaps rsp movaps rsp movaps rsp movaps rsp movaps rsp movaps rsp movaps xmm1

Initial value:

= all-ones
 
and:
     cmpeqps xmm1

Definition at line 38 of file README-SSE.txt.

◆ xmm2

into eax xorps xmm0 xmm0 eax xmm0 eax xmm0 ret esp eax movdqa xmm0 xmm0 esp const ret align it should be movdqa xmm0 xmm0 We should transform a shuffle of two vectors of constants into a single vector of constants insertelement of a constant into a vector of constants should also result in a vector of constants e g VecISelBug ll We compiled it to something globl _t xmm0 movhps xmm0 movss xmm1 movaps xmm2 xmm2 xmm2

Definition at line 39 of file README-SSE.txt.

◆ xmm3

into xmm2 addss xmm2 xmm1 xmm3 addss xmm3 movaps xmm0 unpcklps xmm3

Definition at line 40 of file README-SSE.txt.

Typedefs

Functions

Variables

Typedef Documentation

◆ t

Function Documentation

◆ _mm_set_ps()

◆ c2()

◆ code()

◆ cvtsi2sd()

◆ f32()

◆ fildl()

◆ fldl()

◆ foo()

◆ foo1()

◆ LC0()

◆ load()

◆ madd()

◆ movaps()

◆ movl()

◆ movsd()

◆ movzbl()

◆ norm()

◆ select()

◆ shift_right()

◆ store()

◆ to() [1/2]

◆ to() [2/2]

◆ x()

◆ x2()

◆ x3()

◆ y()

Variable Documentation

◆ __m128i_shift_right

◆ __pad1__

◆ __pad2__

◆ _f

◆ _t

◆ a

◆ add

◆ addl

◆ Also

◆ andnot

◆ B

◆ bad

◆ better

◆ byte

◆ can

◆ code

◆ consider

◆ Currently

◆ double

◆ early

◆ eax

◆ edi

◆ elements

◆ example

◆ gcc

◆ generate

◆ Guide

◆ here

◆ horrible

◆ However

◆ i32

◆ i64

◆ inline

◆ insertps

◆ instruction

◆ instructions

◆ into

◆ it

◆ know

◆ LC0

◆ LCPI1_0

◆ LCPI1_1

◆ like

◆ lowered

◆ mode

◆ model

◆ movl

◆ pad1

◆ pad2