similar to: [LLVMdev] Deep JIT specialization

I don't think there is any infrastructure for this kind of specialization. The closest thing I can think of is the profile-guided optimization stuff that Andreas Neufstifter has worked on. Because compilation and optimization with LLVM is expensive, our approach with Unladen Swallow has been to try to wait longer to generate specialized code, so we don't have to recompile. If memory

Hi Chris, Thanks for pointing me to that presentation! It helped me come up with a strategy that I believe might work: 1) Use CloneFunction() to make a copy of the original unspecialized (but optimized) function. 2) Specialize it using a custom function pass which identifies the specialization parameters and substitutes them with given run-time constants. 3) Run the function through a

On May 27, 2010, at 6:08 AM, Nicolas Capens wrote: > Hi all, > > I'm attempting to use LLVM for run-time code specialization, but I'm facing a performance hurdle. I'm currently performing the specialization during the AST to LLVM IR translation, but unfortunately this leads to relatively slow recompiles as LLVM has to perform all the heavy (optimization) passes over and

Hi all, While profiling LLVM I noticed that a significant amount of time is spent in the RewriteSingleStoreAlloca function. Especially for fairly long basic blocks, linearly searching for uses before a store isn't fast. So I was wondering if there isn't a faster way to locate these uses? Are there any other known opportunities for optimization? I noticed that register allocation

Good morning, Kenneth FYI, Here is my patch for lib/Transforms/IPO/PartialSpecialization.cpp. It works with my several applications but it is not widely tested. The pass had a critical bug, ... when a specialized function is created, all callers are modified. Even if a caller is not needed, to be malformed. My fix includes to examine each of callers to be modified. See also the discussion;

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

Hi all, I've located a regression that causes my project to crash. It's in revision 67979, where PointerIntPair is changed from storing the integer in the upper bits instead of the lower bits. My project is an experimental JIT-compiler in Windows. So I was wondering if anyone had any clue why the new PointerIntPair implementation might fail. It doesn't seem very safe to me to

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

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

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, 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

To elaborate a bit more on the issue that is detailed in https://reviews.llvm.org/rL260308: There are many clang AST contexts that are used in LLDB: - one for each lldb_private::Module that contains type definitions as we know them in the module and its symbol vendor - one for each expression - one for results of expressions in the lldb_private::Target As we run expressions we end up copying

> On Jun 15, 2018, at 9:23 AM, <paul.robinson at sony.com> <paul.robinson at sony.com> wrote: > >> From: Greg Clayton [mailto:clayborg at gmail.com] >> >> ... >> If a class has templated functions, they will only be in the DWARF is a >> specialization was created and used. If you have a class that looks like: >> >> class A { >>

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

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