similar to: [LLVMdev] Modify a module at runtime in MCJIT

Hello, Please, I need more information on the runtime optimizer used in the LLVM JIT. - Where can I find it in the LLVM source code? - Are those runtime optimizations done on the LLVM representation code or on the machine code? Sara -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hello, I'm executing my byte code program by the lli tool using mcjit. I need a way to find statistics about the number of instructions executed for my program. The -stats option does not include this value, are there any other way to know? I need this information to compare different versions of my bytecode program. Please advice Thanks in advance Sara Elsohbaky --------------

Hello, I have the following simple C code below. It should return '8' as a result. But the returned result is false as it returns '1'. When I remove the line of '__attribute__((noinline))' , the returned results are correct '8'. Any idea? Please advice as I need to get the assembly code of the 'getTexSize' function alone. Note: I compile using the

Actually what I meant in my original loop, that there is a dependency between every two consecutive iterations. So, how the loop vectorizer says 'we can vectorize this loop'? for(int k=20;k<50;k++) dataY[k] = dataY[k-1]; From: Henrique Santos [mailto:henrique.nazare.santos at gmail.com] Sent: Sunday, November 03, 2013 4:28 PM To: Sara Elshobaky Cc: <llvmdev at

Hello, I was trying to trace the Loop vectorizer of the LLVM, I wrote a simple loop with a clear dependency. But found that the debug shows that 'we can vectorize this loop' Here you are my loop with dependency: for(int k=20;k<50;k++) dataY[k] = dataY[k-1]; And the debug prints: LV: Checking a loop in "main" LV: Found a loop: for.body4 LV: Found an

Hi Sarah, the loop vectorizer runs not on the C code but on LLVM IR this c code was lowered to. Before the loop vectorizer runs many other optimization change the shape of this IR. You can see in the LLVM IR you referenced below, a preceding LLVM IR transformation has change your loop from: > for(int k=20;k<50;k++) > dataY[k] = dataY[k-1]; to > int a = d[19]; >

Notice that the code you provided, for globals and stack allocations, at least, is semantically equivalent to: int a = d[19]; for(int k = 20; k < 50; k++) dataY[k] = a; Like so, the load you see missing was redundant, probably hoisted by GVN/PRE and replaced with "%.pre". H. On Sun, Nov 3, 2013 at 11:26 AM, Sara Elshobaky <sara.elshobaky at gmail.com>wrote: >

So, what is the use of the profile passes in LLVM? Also, does llvm detect hot blocks of code for recompilation? On Mon, Oct 7, 2013 at 4:44 PM, Amara Emerson <amara.emerson at arm.com> wrote: > No, the JIT does not do any profile guided optimizations for any > architecture. It just uses the static compilation components before loading > the object into memory and running its own

hello, I have a question about the llvm jit. Does it use the profile information generated during runtime to enhance the generated code for arm processor? according to 'LLVM: A Compilation Framework for Lifelong Program Analysis **<http://llvm.org/pubs/2004-01-30-CGO-LLVM.html>' it is available but can't find it in the current source code. I really appreciate any help. Thanks in

Hi, All I m not sure if this question has been asked or not. I'd like cache the MCJIT compiled object into memory buffer so it can be reused later. I followed the Andy Kaylor's example wrote an inherited class from ObjectCache and use raw_fd_ostream to save the cache and load the cache from a file. I checked raw_ostream and its subclass, maybe I am wrong but I don't see one is fit to

Hi all, Starting from Chapter 4 of the Kaleidoscope tutorial (where the JIT support is added), there's some strange behaviour, ready> def foo(x y) x+y; ready> Read function definition: define double @foo(double %x, double %y) { entry: %addtmp = fadd double %x, %y ret double %addtmp } ready> foo(1, 2); ready> Evaluated to 3.000000 ready> foo(3, 4); ready> Evaluated to

> Yep, this is the issue. Running on an ARM pandaboard I can confirm that it's > due > to issues with the old JIT in general which are fixed in MCJIT, and nothing > to do > with the profiling code being tested, as discussed in this thread: > > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120910/150406. > html I don't see this patch get

Oh - I know what this is. You were running this on Linux, right? On MacOS I think the symbol is getting double mangled while going through MCJIT::getSymbolAddress, hence the failure: The IR level foo function gets compiled to "_foo" in the object file, and then "_foo" gets mangled to "__foo" when we look it up. Linux doesn't do assembly level name-mangling, so

Hello, Can LLVM execute OpenGL ES 2.0 programs safely? As I tried a simple code, and I get some crashes while using lli example LLVM ERROR: Program used external function '__dso_handle' which could not be resolved! Thanks in advance Sara Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net -------------- next part

Hi Andrew, On 18/09/12 11:21, David Tweed wrote: > in particular there are some regression tests of interesting things > -- such as profiling -- that fail purely because the default old JIT > doesn't work. |I've actually got LLVM currently compiling within an ARM QEmu install to |look at an assert within the ARM JIT code. Profiling tests that I |submitted a few weeks ago are

Russell Wallace via llvm-dev <llvm-dev at lists.llvm.org> writes: > When writing a JIT compiler using LLVM, as I understand it, you can use two > alternative APIs, MCJIT and Orc. The latter offers lazy compilation. Would > it be accurate to say that if you want eager compilation - always compile > an entire module upfront - you should use MCJIT? +lang. My understanding is that

Out of curiosity, I'm replacing the JIT with MCJIT on my compiler. As all "external" functions are provided by the language's FFI mechanism, it does MyExecutionEngine->DisableSymbolSearching(); MyExecutionEngine->InstallLazyFunctionCreator(&MyLazyFunctionCreator); which works fine with the JIT. However, MCJIT insists on resolving unknown symbols by searching them

Hi, In the process of looking at whether it's reasonable to make ARM use MCJIT by default, I was trying to check that x86-64 uses MCJIT by default (ie, lli doesn't need an explicit -use-mcjit to be passed). However, after instrumenting the constructors for both JIT and MCJIT, either lli doesn't default to using MCJIT on x86-64 or The construction/non-construction of a JIT/MCJIT object

On Wed, Sep 19, 2012 at 12:42:18AM +0000, Kaylor, Andrew wrote: > It seems to me that MCJIT would be a nice default on the platforms that support it. On the other hand, I don't like the idea of the default behavior being platform dependent. > > Perhaps the biggest obstacle to changing the default is that it would have complicated implications for the automated tests. The testing of

When writing a JIT compiler using LLVM, as I understand it, you can use two alternative APIs, MCJIT and Orc. The latter offers lazy compilation. Would it be accurate to say that if you want eager compilation - always compile an entire module upfront - you should use MCJIT? -------------- next part -------------- An HTML attachment was scrubbed... URL: