similar to: [LLVMdev] Output to a DLL

"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 trivial to do. I don't know your requirements, but mine is to avoid

When you say "spit bitecode from the JIT the first time, load it on subsequent sessions" : - do you want to write the IR in a file via BitcodeWriter and re-read it via BitcodeReader ? (you will pay the cost of native code emission on each load ?) - do you want to write the native code ? In that case, how do you retrieve the size of the buffer prepared by the

On Thu, Jun 11, 2009 at 7:34 AM, Nicolas Capens<nicolas at capens.net> wrote: > 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? You can't use the JIT to compile code for a DLL; it simply isn't designed for that. > Or would it be straightforward to write my own DLL writer

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 number of byte moves). I think some changes related to

This thread confuses me. I thought Chris said that LLVM 2.8 will not lower generic vectors to MMX because it breaks x87 code, and I didn't see an answer to your 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

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

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'm a little bit worried about the sheer size of the resulting binaries of a project using LLVM. The medium large project for which I'm planning to use it (which currently uses a custom dynamic code generator), produces a compact 1.6 MB binary. When I compile LLVM's simple 'Fibonacci' example project the executable is 2.6 MB. I realize LLVM is a complex and

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 03A70011 mov ebp,esp 03A70013 and esp,0FFFFFFF0h 03A70019 sub esp,1A0h ... 03A7006C movups xmmword ptr

Hi all, After creating a new LLVM-based project, I faced an odd problem. ExecutionEngine::create always retuned null. After some investigation I found out that it was due to the target architecture not getting registered. I'm using Visual C++ 2005 and in the X86TargetMachine.cpp file an extern variable X86TargetMachineModule is created to 'ensure' that the module is linked in. It

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 not sure it's worth bothering. -Eli

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

Hi all, I'm trying to use LLVM to generate SIMD code at runtime (in particular Intel 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

On Sep 21, 2010, at 5:30 PMPDT, Bill Wendling wrote: > LLVM isn't going to stop generating MMX instructions all together. We can't do that. :-) If the user specifically wants MMX (by, say, using the builtins), we have to support that still. The plan to cease generating MMX for generic vectors is a work-in-progress right now. It's not in 2.8. > > -bw Right, early on there

Hi all, I'm hitting the following assert in PredicateSimplifier.cpp:961 : assert(!CR.isSingleElement() && "Refusing to store single element."); If I ignore it the generated code appears correct so I'm not sure what this assert is supposed to be for. Am I doing something wrong on my end or is this a superfluous assert or it really indicates an LLVM bug? The

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 bit of the return value of VFCmp is defined (according to

Hi Jeffrey, Please correct me if I'm wrong, but I believe a test that checks for the old behavior would be pointless. I realize that my patch would return an unmatching intrinsicID when the function's name changes, but the real question we should ask is do we really want to be able to change the intrinsicID by changing the function's name? Also, the original Function constructor

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 visitAnd, visitOr and vistXor, I’ve only been able to

LLVM isn't going to stop generating MMX instructions all together. We can't do that. :-) If the user specifically wants MMX (by, say, using the builtins), we have to support that still. The plan to cease generating MMX for generic vectors is a work-in-progress right now. It's not in 2.8. -bw On Sep 21, 2010, at 4:24 PM, Reid Kleckner wrote: > This thread confuses me. I thought

Hi all, I was wondering how to use variations of intrinsic functions that take a memory operand. Take for example the SSE4.1 pmovsxbd instruction. One variant takes two XMM registers, while another has a 32-bit memory location as source operand. The latter is quite interesting if you know you're reading from memory anyway, and if it's not 16-byte aligned. It looks like LLVM's