search for: vfcmp

Hi all, When trying to generate a VFCmp instruction when UnsafeFPMath is set to true I get an assert "Unexpected CondCode" on my x86 system. This also happens with UnsafeFPMath set to false and using an unordered compare. Could someone look into this? While I'm at it, is there any reason why only the most significant bi...

Hi Chris, I've attached a replacement of fibonacci.cpp that reproduces the issue on x86/SSE systems. Regarding the definition of the VFCmp instruction, I think it would really be a lot more valuable to define it as returning all 1's or all 0's per element. Just setting the most significant bit is pretty much worthless (someone correct me if I'm wrong). I checked and I couldn't actually find any instruction set that onl...

On Jun 13, 2008, at 12:27 AM, Nicolas Capens wrote: > Hi all, > > When trying to generate a VFCmp instruction when UnsafeFPMath is set > to true I get an assert “Unexpected CondCode” on my x86 system. This > also happens with UnsafeFPMath set to false and using an unordered > compare. Could someone look into this? Please provide a testcase. > > While I’m at it, is there a...

On Jun 13, 2008, at 12:27 AM, Nicolas Capens wrote: > Hi all, > > When trying to generate a VFCmp instruction when UnsafeFPMath is set > to true I get an assert “Unexpected CondCode” on my x86 system. This > also happens with UnsafeFPMath set to false and using an unordered > compare. Could someone look into this? Have you filed a bug? > > While I’m at it, is there any re...

....0f; if(v[3] < 0) v[3] += 1.0f; With SSE assembly this would be as simple as: movaps xmm1, xmm0 // v in xmm0 cmpltps xmm1, zero // zero = {0.0f, 0.0f, 0.0f, 0.0f} andps xmm1, one // one = {1.0f, 1.0f, 1.0f, 1.0f} addps xmm0, xmm1 With the current definition of VFCmp this seems hard if not impossible to achieve. Vector compare instructions that return all 1's or all 0's per element are very common, and they are quite powerful in my opinion (effectively allowing to implement a per-element Select). It seems to me that for the few architectures that don...

On Jun 13, 2008, at 12:27 AM, Nicolas Capens wrote: > Hi all, > > When trying to generate a VFCmp instruction when UnsafeFPMath is set > to true I get an assert “Unexpected CondCode” on my x86 system. This > also happens with UnsafeFPMath set to false and using an unordered > compare. Could someone look into this? > > While I’m at it, is there any reason why only the most s...

On Jun 24, 2009, at 10:02 AM, Chris Lattner wrote: > > On Jun 24, 2009, at 12:47 AM, Duncan Sands wrote: > >> Hi Nick, >> >>> Now that icmp and fcmp have supported returning vectors of i1 for a >>> while, >> >> the code generators don't know how to codegen vectors of i1, so does >> this actually work? > > No, but there are no

Now that icmp and fcmp have supported returning vectors of i1 for a while, I think it's time to remove the vicmp and vfcmp instructions from LLVM. The good news is that we've never shipped a release that included them so we won't be providing auto-upgrade support. There is some existing backend support for vicmp and vfcmp that looks different from what icmp and fcmp do. If this actually matters to you, ple...

On Jun 24, 2009, at 12:47 AM, Duncan Sands wrote: > Hi Nick, > >> Now that icmp and fcmp have supported returning vectors of i1 for a >> while, > > the code generators don't know how to codegen vectors of i1, so does > this actually work? No, but there are no clients of them yet. -Chris

Hi Nick, > Now that icmp and fcmp have supported returning vectors of i1 for a > while, the code generators don't know how to codegen vectors of i1, so does this actually work? Ciao, Duncan.

Hi. The attached patch adds wrappers for the instructions vicmp, vfcmp, ret (multiple) and getresult, and for the vicmp and vfcmp operations on constants, to llvm-c. Also: 1) There appears to be no way to create intrinsics via llvm-c. Is there? 2) The "extractvalue"[1] and "insertvalue"[2] instructions don't seem to be addable via IRBuilder....

...reporting any problems you encounter. > > > 2. vector select [...] > > 3. vector trunc, sext, zext, fptrunc, fpext [...] > > 4. vector shl, lshr, ashr [...] We agree that these would be useful. There are intentions to add them to LLVM; others can say more. > > > 4. vfcmp, vicmp return types > > This topic came up recently on llvm-dev (thread "VFCmp failing when > unordered or UnsafeFPMath on x86"). Having vector compares return a > vector of integer elements with bit width equal to the element types > being compared seems unnecessarily inco...

...here are of course two ways to interpret a shift on a vector type: within elements and across elements. To us, shifts within elements (i.e. the equivalent of N scalar shifts) are more important than shifts (or rotates!) across elements, but the latter could be useful in some situations as well. 4. vfcmp, vicmp return types This topic came up recently on llvm-dev (thread "VFCmp failing when unordered or UnsafeFPMath on x86"). Having vector compares return a vector of integer elements with bit width equal to the element types being compared seems unnecessarily inconsistent with the icmp a...

...ing this to the IR gets you for vectors, since "vector of i1" doesn't mean "vector of bits" necessarily. > 5) Vector comparisons that return <N x i1> > > This is maybe not a must-have, and perhaps more a question of > preference. I understand the current vfcmp/vicmp semantics, returning > a vector of iK where K matches the bitwidth of the operands being > compared with the high bit set or not, are there for pragmatic > reasons, and that these functions exist to aid with code emitted that > uses machine-specific intrinsics. I totally disagree...

Hi. Version 0.5 of llvm-py, Python bindings for LLVM, has been released. This version supports (only) LLVM 2.4. New instructions of LLVM 2.4 (vicmp, vfcmp, insertvalue, extractvalue) are available. Home page: http://mdevan.nfshost.com/llvm-py/ Feedback welcome. Thanks & Regards, -Mahadevan.

...pretty much broken and unimplemented. They can be > removed pretty soon (say, after 2.8) We've never released with unions. Could we remove them for the 2.8 release instead of afterwards when they're part of our forever forwards compatible bitcode format? Similar to what we did to the vfcmp and ficmp instructions maybe?

...sext, zext, fptrunc, fpext >> 4. vector shl, lshr, ashr > [...] > > We agree that these would be useful. There are intentions to add them > to LLVM; others can say more. OK. I'd love to hear more, especially if someone is planning to do this in the short term. >> 4. vfcmp, vicmp return types >> >> This topic came up recently on llvm-dev (thread "VFCmp failing when >> unordered or UnsafeFPMath on x86"). Having vector compares return a >> vector of integer elements with bit width equal to the element types >> being compared seem...

...k to select between elements of <N x T> vectors for some basic type T. Vector min, max, sign, etc. can be built on top of this operation. 5) Vector comparisons that return <N x i1> This is maybe not a must-have, and perhaps more a question of preference. I understand the current vfcmp/vicmp semantics, returning a vector of iK where K matches the bitwidth of the operands being compared with the high bit set or not, are there for pragmatic reasons, and that these functions exist to aid with code emitted that uses machine-specific intrinsics. For code that does not use mac...

...et=US-ASCII; format=flowed; delsp=yes > > > On Nov 22, 2008, at 8:59 AM, Mahadevan R wrote: > >> Hi. >> >> Version 0.5 of llvm-py, Python bindings for LLVM, has been released. >> This version supports (only) LLVM 2.4. New instructions of LLVM 2.4 >> (vicmp, vfcmp, insertvalue, extractvalue) are available. >> >> Home page: http://mdevan.nfshost.com/llvm-py/ > > This is *very* cool. We don't currently have a good way to host links > to projects like yours, but I added it to this page (at the bottom): http://llvm.org/Users.html Um, i...

...ed. They can be >> removed pretty soon (say, after 2.8) > > We've never released with unions. Could we remove them for the 2.8 > release instead of afterwards when they're part of our forever forwards > compatible bitcode format? > > Similar to what we did to the vfcmp and ficmp instructions maybe? I'm for it. I thought I'd seen something to that effect anyhow. -eric