search for: pcmpeq

...ced with native IR over the years. Has enough time and/or versions passed that we can begin phasing out some of this code? As I'm writing these we don't seem to have tests for a lot of the older upgrades. We've done better at this in the last few years. 3.1 added upgrade for: x86.sse2.pcmpeq.* - we have almost no test cases for this x86.sse2.pcmpgt.* - we no test cases for this x86.avx2.pcmpeq.* - we have no test cases x86.avx2.pcmpgt.* - we have no test cases for this x86.avx.vpermil.* - we do test this 3.2 added upgrade for: x86.avx.movnt.* - we have tests for this x86.xop.vpcom*...

.... Has enough time > and/or versions passed that we can begin phasing out some of this code? > > As I'm writing these we don't seem to have tests for a lot of the older > upgrades. We've done better at this in the last few years. > > 3.1 added upgrade for: > x86.sse2.pcmpeq.* - we have almost no test cases for this > x86.sse2.pcmpgt.* - we no test cases for this > x86.avx2.pcmpeq.* - we have no test cases > x86.avx2.pcmpgt.* - we have no test cases for this > x86.avx.vpermil.* - we do test this > > 3.2 added upgrade for: > x86.avx.movnt.* - we h...

...nd/or versions passed that we can begin phasing out some of this code? >> >> As I'm writing these we don't seem to have tests for a lot of the older >> upgrades. We've done better at this in the last few years. >> >> 3.1 added upgrade for: >> x86.sse2.pcmpeq.* - we have almost no test cases for this >> x86.sse2.pcmpgt.* - we no test cases for this >> x86.avx2.pcmpeq.* - we have no test cases >> x86.avx2.pcmpgt.* - we have no test cases for this >> x86.avx.vpermil.* - we do test this >> >> 3.2 added upgrade for: &gt...

...years. Has enough time and/or versions passed that we can begin phasing out some of this code? > > As I'm writing these we don't seem to have tests for a lot of the older upgrades. We've done better at this in the last few years. > > 3.1 added upgrade for: > x86.sse2.pcmpeq.* - we have almost no test cases for this > x86.sse2.pcmpgt.* - we no test cases for this > x86.avx2.pcmpeq.* - we have no test cases > x86.avx2.pcmpgt.* - we have no test cases for this > x86.avx.vpermil.* - we do test this > > 3.2 added upgrade for: > x86.avx.movnt.* - we...

...ced with native IR over the years. Has enough time and/or versions passed that we can begin phasing out some of this code? As I'm writing these we don't seem to have tests for a lot of the older upgrades. We've done better at this in the last few years. 3.1 added upgrade for: x86.sse2.pcmpeq.* - we have almost no test cases for this x86.sse2.pcmpgt.* - we no test cases for this x86.avx2.pcmpeq.* - we have no test cases x86.avx2.pcmpgt.* - we have no test cases for this x86.avx.vpermil.* - we do test this 3.2 added upgrade for: x86.avx.movnt.* - we have tests for this x86.xop.vpcom*...

.... Has enough time > and/or versions passed that we can begin phasing out some of this code? > > As I'm writing these we don't seem to have tests for a lot of the older > upgrades. We've done better at this in the last few years. > > 3.1 added upgrade for: > x86.sse2.pcmpeq.* - we have almost no test cases for this > x86.sse2.pcmpgt.* - we no test cases for this > x86.avx2.pcmpeq.* - we have no test cases > x86.avx2.pcmpgt.* - we have no test cases for this > x86.avx.vpermil.* - we do test this > > 3.2 added upgrade for: > x86.avx.movnt.* - we h...

...creates various improvements and regression to the existing test suite. I'd like to work through as many of the regressions as possible ahead of time. One source of such regressions is combineIncDecVector in the X86 backend. It changes (add X, 1) into (sub X, -1) in order to be able to use the pcmpeq instruction. This is all well and good, but numerous paterns are matching an add rather than a sub, and in fact, DAGCombiner does the inverse transform by itself as it consider the add form to be canonical. An example of such pattern is the X86ISD::AVG node, but there are more. It seems to me lik...

...aches 1 and 2 depend on some stuff that hasn't really stabilized > yet... you should get much better results with vicmp. Oh wait, I just realized vicmp is a post-2.4 thing... if you really want to generate an SSE comparison using LLVM 2.4, you can use the x86 intrinsics, like @llvm.x86.sse2.pcmpeq.b. -Eli

...egression to the existing test suite. I'd > like to work through as many of the regressions as possible ahead of time. > > > > One source of such regressions is combineIncDecVector in the X86 > backend. It changes (add X, 1) into (sub X, -1) in order to be able to use > the pcmpeq instruction. > > > > This is all well and good, but numerous paterns are matching an add > rather than a sub, and in fact, DAGCombiner does the inverse transform by > itself as it consider the add form to be canonical. An example of such > pattern is the X86ISD::AVG node, but t...

...creates various improvements and regression to the existing test suite. I'd like to work through as many of the regressions as possible ahead of time. One source of such regressions is combineIncDecVector in the X86 backend. It changes (add X, 1) into (sub X, -1) in order to be able to use the pcmpeq instruction. This is all well and good, but numerous paterns are matching an add rather than a sub, and in fact, DAGCombiner does the inverse transform by itself as it consider the add form to be canonical. An example of such pattern is the X86ISD::AVG node, but there are more. It seems to me like...

On Thu, Dec 25, 2008 at 1:28 AM, Claudio Basile <cbasile at tempo-da.com> wrote: > Hi all, > > is there any way to compare two 128bit values? > I have tried 3 different approaches and they all fail with an internal > assertion. > I'm running llvm 2.4 on x86 with the following command line: > > > llvm-as test.ll -o test.bc > > llc test.bc -filetype=asm

...some stuff that hasn't really stabilized >> yet... you should get much better results with vicmp. > > Oh wait, I just realized vicmp is a post-2.4 thing... if you really > want to generate an SSE comparison using LLVM 2.4, you can use the x86 > intrinsics, like @llvm.x86.sse2.pcmpeq.b. Thanks for your answer. It looks like vicmp is part of LLVM 2.4. It is documented there, at least. How do you suggest I use it to compare two vector operands? I'd guess I could generate a mask by extracting the most significant bits in each words, but that approach doesn't work per...

Hi all, is there any way to compare two 128bit values? I have tried 3 different approaches and they all fail with an internal assertion. I'm running llvm 2.4 on x86 with the following command line: > llvm-as test.ll -o test.bc > llc test.bc -filetype=asm I would expect the code generator to emit a sequence of SSE instructions.

...calar operations is slower than using vector operations. In LLVM, vector-compare operations generate a vector of i1s, and the vector-select instruction uses these vectors. In between, these values (masks) can be manipulated (xor-ed, and-ed, etc). For x86, I would like the codegen to generate the ‘pcmpeq’ and ‘blend’ family of instructions.  SSE masks are implemented using a 32bit word per item, where the MSB bit is used as a predicate and the rest of the bits are ignored.  I believe that  PPC Altivec and ARM Neon are also implemented this way. I can think of two ways to represent masks in x86: s...