search for: movapd

...The generated instruction varies, but >>>>>> it seems to often be similar to (I >>>>>> don't have it in front of me, sorry): >>>>>> movapd xmm0, xmm[ecx+0x???????] >>>>>> Where the xmm register changes, and >>>>>> the second parameter is a memory access. >>>>>> ECX is always set to 0x7ffffff - >&...

...or the aligned case, I want to measure performance degradation for unaligned case. I mean unaligned case versus aligned. I know this is stupid, but I want to try to pass a <4 x float>* as parameter of a routine and at the call site I want to pass a misaligned pointer. Since LLVM is generating movapd instruction it will raise an exception (SEGFAULT), I just want to know if there is a way to enforce generation of movupd instruction instead of movapd. Seb > -----Original Message----- > From: David A. Greene [mailto:greened at obbligato.org] > Sent: Friday, February 25, 2011 5:13 PM &g...

Hi all, Is there a way to force llc to generate movupd instruction instead of movapd for x86 target ? I know that movapd is more performant, but I would like to measure degradation when alignment constraints are not met. Best Regards Seb -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110225...

...e aligned case, I want to measure performance degradation for unaligned case. > I mean unaligned case versus aligned. I know this is stupid, but I want to try to pass a <4 x float>* as parameter of a routine and at the call site I want to pass a misaligned pointer. Since LLVM is generating movapd instruction it will raise an exception (SEGFAULT), I just want to know if there is a way to enforce > generation of movupd instruction instead of movapd. If llvm is generating movapd then it believes the pointer is aligned. Without having more information it's impossible to tell what the i...

Sebastien DELDON-GNB <sebastien.deldon at st.com> writes: > Hi all, > > Is there a way to force llc to generate movupd instruction instead of movapd for x86 target ? > > I know that movapd is more performant, but I would like to measure degradation when alignment constraints are not met. On modern processors a movupd on aligned data is going to be indistinguishable in performance from a movapd. -Dave

...he SSE >>>>>>> fault raising mechanism appears. >>>>>>> >>>>>>> The generated instruction varies, but it seems to often be similar >>>>>>> to (I don't have it in front of me, sorry): >>>>>>> movapd xmm0, xmm[ecx+0x???????] >>>>>>> Where the xmm register changes, and the second parameter is a memory >>>>>>> access. >>>>>>> ECX is always set to 0x7ffffff - however I don't know if this is >>>>>>> part of the...

On Tuesday 02 September 2008 16:47, Evan Cheng wrote: > On Sep 2, 2008, at 10:42 AM, David Greene wrote: > > Is there an easy way to get the MVT::ValueType of a MachineInstruction > > MachineOperand? For example, the register operand of an x86 MOVAPD > > should > > have an MVT::ValueType of v2f64. A MOVAPS register operand should > > have an > > MVT::ValueType of v4f32. > > The short answer is no. A op of a number of different VTs can map to > the same instruction. In general, that may be true, but for most i...

...e wrote: > On Tuesday 02 September 2008 16:47, Evan Cheng wrote: >> On Sep 2, 2008, at 10:42 AM, David Greene wrote: >>> Is there an easy way to get the MVT::ValueType of a >>> MachineInstruction >>> MachineOperand? For example, the register operand of an x86 MOVAPD >>> should >>> have an MVT::ValueType of v2f64. A MOVAPS register operand should >>> have an >>> MVT::ValueType of v4f32. >> >> The short answer is no. A op of a number of different VTs can map to >> the same instruction. > > In general,...

Is there an easy way to get the MVT::ValueType of a MachineInstruction MachineOperand? For example, the register operand of an x86 MOVAPD should have an MVT::ValueType of v2f64. A MOVAPS register operand should have an MVT::ValueType of v4f32. So given a MachineInstruction and its MachineOperands is there some easy way to derive this information? I don't see anything in TargetInstrInfo that would help....

On Sep 2, 2008, at 10:42 AM, David Greene wrote: > Is there an easy way to get the MVT::ValueType of a MachineInstruction > MachineOperand? For example, the register operand of an x86 MOVAPD > should > have an MVT::ValueType of v2f64. A MOVAPS register operand should > have an > MVT::ValueType of v4f32. The short answer is no. A op of a number of different VTs can map to the same instruction. However, given a register class you can get to the list of VTs that map...

...800,3 # @Y .comm _X,800,3 # @X gcc -S -O3 -o test2.s test.c -march=native result: .file "test.c" .text .p2align 4,,15 .globl _f .def _f; .scl 2; .type 32; .endef _f: pushl %ebp movddup _DA, %xmm2 movl %esp, %ebp xorl %eax, %eax .p2align 4,,10 L2: movapd _Y(%eax), %xmm0 movapd _X(%eax), %xmm1 mulpd %xmm2, %xmm1 subpd %xmm1, %xmm0 movapd %xmm0, _Y(%eax) addl $16, %eax cmpl $800, %eax jne L2 xorw %ax, %ax leave ret .globl _DA .data .align 16 _DA: .long 858993459 .long 1070805811 .comm _X, 800, 5 .comm _Y, 800, 5 It seems gcc emit mor...

...16 byte aligned. I notice that the offset is aligned though. The crash occurs on the first instance of addpd applied to the stack (as I understand ESP is used for). There is also raises the question of would it be worth requiring alignment of the function stack to improve performance (assuming movapd is faster then movupd). I'm not expecting LLVM to recognize this (although it would be neat) but is this something worth setting ourselves, knowing we're going to be using mostly SSE instructions? And how would we do that? -- Peter N -------------- next part -------------- A non-text a...

...ction/Module. It crashes with what is reported as a memory access error (accessing 0xffffffff), however it's suggested that this is how the SSE fault raising mechanism appears. The generated instruction varies, but it seems to often be similar to (I don't have it in front of me, sorry): movapd xmm0, xmm[ecx+0x???????] Where the xmm register changes, and the second parameter is a memory access. ECX is always set to 0x7ffffff - however I don't know if this is part of the SSE error reporting process or is part of the situation causing the error. I haven't worked out exactly what...

.... It crashes with what is reported as a memory access error (accessing 0xffffffff), however it's suggested that this is how the SSE fault raising mechanism appears. > > The generated instruction varies, but it seems to often be similar to (I don't have it in front of me, sorry): > movapd xmm0, xmm[ecx+0x???????] > Where the xmm register changes, and the second parameter is a memory access. > ECX is always set to 0x7ffffff - however I don't know if this is part of the SSE error reporting process or is part of the situation causing the error. > > I haven't worked...

...ret void } declare x86_mmx @llvm.x86.mmx.punpcklbw(x86_mmx, x86_mmx) nounwind readnone Which gives me the following assembly code: push ebp mov ebp,esp and esp,0FFFFFFF0h sub esp,20h mov eax,dword ptr [ebp+0Ch] movd xmm0,dword ptr [eax] movapd xmmword ptr [esp],xmm0 movq mm0,mmword ptr [esp] punpcklbw mm0,mm0 mov eax,dword ptr [ebp+8] movq mmword ptr [eax],mm0 emms mov esp,ebp pop ebp ret The inner portion could look like this instead: movd mm0,dword ptr [eax] punp...

...6.mmx.punpcklbw(x86_mmx, x86_mmx) nounwind readnone > > Which gives me the following assembly code: > > push ebp > mov ebp,esp > and esp,0FFFFFFF0h > sub esp,20h > mov eax,dword ptr [ebp+0Ch] > movd xmm0,dword ptr [eax] > movapd xmmword ptr [esp],xmm0 > movq mm0,mmword ptr [esp] > punpcklbw mm0,mm0 > mov eax,dword ptr [ebp+8] > movq mmword ptr [eax],mm0 > emms > mov esp,ebp > pop ebp > ret > > The inner portion could look like this instead: > &...

...g 0xffffffff), however it's suggested that this is how the SSE >>>> fault raising mechanism appears. >>>> >>>> The generated instruction varies, but it seems to often be similar to >>>> (I don't have it in front of me, sorry): >>>> movapd xmm0, xmm[ecx+0x???????] >>>> Where the xmm register changes, and the second parameter is a memory >>>> access. >>>> ECX is always set to 0x7ffffff - however I don't know if this is part >>>> of the SSE error reporting process or is part of the si...

...s that load xmm0 and xmm1. I started looking at some performance counters on Friday, but I did not find anything suspicious yet. +0x00 movupd 16(%rsi), %xmm0 +0x05 movupd 16(%rsp), %xmm1 +0x0b subpd %xmm1, %xmm0 <———— 18% of the runtime of bh ? +0x0f movapd %xmm0, %xmm2 +0x13 mulsd %xmm2, %xmm2 +0x17 xorpd %xmm1, %xmm1 +0x1b addsd %xmm2, %xmm1 I spent less time on Bullet. Bullet also has one hot function (“resolveSingleConstraintRowLowerLimit”). On this code the vectorizer generates severa...

...ffff), however it's suggested that this >> is how the SSE fault raising mechanism appears. >> >> The generated instruction varies, but it seems to often >> be similar to (I don't have it in front of me, sorry): >> movapd xmm0, xmm[ecx+0x???????] >> Where the xmm register changes, and the second parameter >> is a memory access. >> ECX is always set to 0x7ffffff - however I don't know if >> this is part of the SSE error reporting process or i...

...er it's suggested that this is how the SSE >>>>> fault raising mechanism appears. >>>>> >>>>> The generated instruction varies, but it seems to often be similar to >>>>> (I don't have it in front of me, sorry): >>>>> movapd xmm0, xmm[ecx+0x???????] >>>>> Where the xmm register changes, and the second parameter is a memory >>>>> access. >>>>> ECX is always set to 0x7ffffff - however I don't know if this is part >>>>> of the SSE error reporting process or i...