search for: capens

Assign the bug to me and I'll fix it in TOT next week! Thanks for narrowing it down! On Wednesday, September 22, 2010, Nicolas Capens <nicolas.capens at gmail.com> wrote: > Hi all, > > I think I figured it out: > 112804 causes 64-bit UNPCKLBW to no longer be selected for certain cases. > 112805 is benign. > 112806 causes 64-bit UNPCKHBW to no longer be selected for certain cases. > > I've attache...

On Wed, Sep 8, 2010 at 12:35 AM, Nicolas Capens <nicolas.capens at gmail.com> wrote: > Hi Chris, > > It's not broken, but the performance is crippled. > > I noticed that the code still contains some MMX instructions, but several > operations get expanded (apparently swizzling and such get expanded to a > large numb...

...our question about a switch to tell the code generator otherwise. However, you're complaining that MMX performance is subpar, even though LLVM 2.8 isn't supposed to generate MMX instructions. Can someone clarify the situation for me? Thanks, Reid On Tue, Sep 21, 2010 at 6:13 PM, Nicolas Capens <nicolas.capens at gmail.com> wrote: > Hi Dale, > > I suspect that these patches were intended to improve 128-bit vector > performance but caused certain 64-bit vector operations to no longer lower > to MMX instructions. Anyway, now that I've narrowed it down to these patch...

...sp+180h] Note how stores and loads use unaligned moves while it could use aligned moves. It's also interesting that the multiply does correctly assume the stack to be 16-byte aligned. Is there something I'm doing wrong (again), or is this already known? Thanks a lot, Nicolas Capens -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080714/2854bfae/attachment.html> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: fibonacci.cpp URL...

On Tue, Jun 9, 2009 at 2:58 PM, Nicolas Capens<nicolas at capens.net> wrote: > Please consider committing the attached patch. I believe the SSE2 packsswb, > packssdw and packuswb intrinsics have an incorrect return type. If we really wanted to do this, an AutoUpgrade patch would be necessary for backwards-compatibility. I'm no...

Hi all, Please consider committing the attached patch. I believe the SSE2 packsswb, packssdw and packuswb intrinsics have an incorrect return type. Thanks, Nicolas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090609/85ed0b5e/attachment.html> -------------- next part -------------- A

Hi all, I'd like to be able to write JIT-compiled code to a Windows DLL. I have no idea where to start though. Does LLVM already offer some support for this? Or would it be straightforward to write my own DLL writer (no advanced features needed)? Or maybe I could use an external linker? All help highly appreciated! Cheers, Nicolas -------------- next part -------------- An HTML

...e documented somewhere. So unless there are tangible reasons why intrinsics should actually be allowed to change name I believe my patch is valid. Cheers, Nicolas -----Original Message----- From: Jeffrey Yasskin [mailto:jyasskin at google.com] Sent: Saturday, 17 October, 2009 19:03 To: Nicolas Capens Cc: LLVM Developers Mailing List Subject: Re: [LLVMdev] getIntrinsicID() optimization, mark 2 It is possible to change the name of a Function with Value::setName, so this patch _could_ cause incorrect answers. You should add a test that calls setName("intrinsic.name") to make sure this k...

...generator otherwise. However, you're complaining that MMX performance > is subpar, even though LLVM 2.8 isn't supposed to generate MMX > instructions. > > Can someone clarify the situation for me? > > Thanks, > Reid > > On Tue, Sep 21, 2010 at 6:13 PM, Nicolas Capens > <nicolas.capens at gmail.com> wrote: >> Hi Dale, >> >> I suspect that these patches were intended to improve 128-bit vector >> performance but caused certain 64-bit vector operations to no longer lower >> to MMX instructions. Anyway, now that I've narro...

...39;re complaining that MMX performance >> is subpar, even though LLVM 2.8 isn't supposed to generate MMX >> instructions. >> >> Can someone clarify the situation for me? >> >> Thanks, >> Reid >> >> On Tue, Sep 21, 2010 at 6:13 PM, Nicolas Capens >> <nicolas.capens at gmail.com> wrote: >>> Hi Dale, >>> >>> I suspect that these patches were intended to improve 128-bit vector >>> performance but caused certain 64-bit vector operations to no longer lower >>> to MMX instructions. Anyway,...

...lue to X86TargetMachineModule in another module, all is fine and dandy. Although it's a viable workaround for now I was wondering if anyone knew a more elegant solution, or has an explanation why X86TargetMachineModule works for the example projects but not for mine. Thanks, Nicolas Capens -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080527/0b73ecda/attachment.html>

On Wed, Jul 29, 2009 at 3:45 AM, Nicolas Capens<nicolas at capens.net> wrote: > So could anyone who knows the ins and outs of this code have a look at how > to make it handle vectors correctly? Or if that’s not an option right now, > please revert the broken optimizations. Note that there might be more things > affected than vi...

...s quite interesting if you know you're reading from memory anyway, and if it's not 16-byte aligned. It looks like LLVM's Intrinsic::x86_sse41_pmovsxbd expects a v16i8 as source operand though. So how do I achieve using the variant taking a memory operand? Thanks a bunch, Nicolas Capens -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080801/721d443e/attachment.html>

...s -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Eli Friedman Sent: woensdag 29 juli 2009 20:44 To: LLVM Developers Mailing List Subject: Re: [LLVMdev] Vector logic regression in r73431 On Wed, Jul 29, 2009 at 3:45 AM, Nicolas Capens<nicolas at capens.net> wrote: > So could anyone who knows the ins and outs of this code have a look at > how to make it handle vectors correctly? Or if that's not an option > right now, please revert the broken optimizations. Note that there > might be more things affected...

...w how to 'reinterpret_cast' values. It can be quite useful to sometimes interpret a vector of floating-point values as a vector of integers (for instance to extract the sign, exponent and/or mantissa bits). Any information on how to do that would be much appreciated. Thanks, Nicolas Capens -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080520/a1db13b6/attachment.html>

...according to the documentation)? Both AltiVec and SSE set the components of the result to either all 1's or all 0's. Having only the most significant bit doesn't seem useful to me at all, and (arithmetic) shifting vectors to replicate the bit isn't supported. Thanks! Nicolas Capens -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080613/3831507d/attachment.html>

"Nicolas Capens" <nicolas at capens.net> writes: Hello Nicolas. > I'd like to be able to write JIT-compiled code to a Windows DLL. I have no > idea where to start though. Does LLVM already offer some support for > this? Nope. Don't hold your breadth waiting for it. It is far from tri...

...ntel SSE). But I'm having a bit of trouble understanding how to create even the simplest function; adding two vectors of four single-precision floating-point elements. I can get it to add the elements one at a time but not using one vector instruction. All help much appreciated! Nicolas Capens -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080508/967e796c/attachment.html>

Hi All, I found a regression which triggers the asserts: "Binary operator types must match!" and "Op types should be identical!". It's happening with a piece of vector code, and the asserts happen because a logic operation is attempted between a vector and a scalar (which is not present in the original code, but created by InstCombine). It's caused by revision

...t doesn't happen until post- register allocation. Assuming there aren't other instructions between the prologue and the first movups that mess up esp (there shouldn't), this is indeed a bug. Please file a bug and attach a bc file. Thanks. Evan On Jul 14, 2008, at 7:43 AM, Nicolas Capens wrote: > Hi all, > > It looks like vector spills don’t use aligned moves even though the > stack is aligned. This seems like an optimization opportunity. > > The attached replacement of fibonacci.cpp generates x86 code like > this: > > 03A70010 push ebp >...