similar to: [LLVMdev] Drop the machine code while executing

That's a good point.  But it's worth noting that recompileAndRelinkFunction() and freeMachineCodeForFunction() are both vestiges of the old JIT (i.e. the "JIT" as opposed to the "MCJIT").  The old JIT is no longer actively supported. -Phil On April 26, 2014 at 9:47:05 AM, Sri (emdcdeveloper at gmail.com) wrote: Hi Fillip                  Addition to my previous

Hi Filip Thank you for your detailed explanation, I was actually looking to implement an adaptive approach which is basically when some function executed more frequently, I was trying to drop that function and compiled and linked with new optimized function. I just did the following - whenever some function executed more times , I called-back to program, so I that I

I believe the perf tool cannot profile/analyze the JITed code in MCJIT model. Can you please confirm this ? I was working on a patch to fix this. Another question, is the there any support to map the llvm IR with x86 generated assembly ? so its easier to analyze the code generator. -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi VMKit JIT has a function cache to store compiled IR code , so, as soon as method is compiled , it will be stored in to function cache. My question is , who will use this compiled information from function cache. Since we are jitting , the llvm translate source code in to native code and executing them . So, how we relates this function cache with JIT ? Thanks Regards Sri.

Hi Gael I am sorry that I couldn't explain what I was trying to say, anyway I've got the answer :) . In the *parseFunction* method returns *llvmfunction* pointer of compiled method and then it will be stored in to cache. Could you please more elaborate on how those machine instructions ( native functions) executing by llvm. I was trying trace and I couldn't able to find

Hi All I am trying to trace the execution path of J3 jvm with input of java byte code . Once java byte codes compiled in to llvm IR it will be passed to VMKit for store them . I couldn't find out which function is getting this Jitted output from *Functioncache* and executing them ? because , VMKit doesn't have an implementation of llvm Executionengine's *runFunction*

Hi Does anybody use *StartJnjvmWithJIT* from jvjvm.cpp in VMKit? Becuase , I am looking to use without JIT when we are running the Java byte code. My concern is StartJnjvmWithJIT getting three argument *int argc, char** argv, char* mainClass* - why we need to pass *argv and mainclass* arguments here? please help me on this. Regards Sri. -------------- next part -------------- An

Hello LLVM community, Over the last few years the LLVM team here at Apple and development teams elsewhere have been busily working on finding new and interesting uses for LLVM. Some of these uses are traditional compilers, but a growing number of them aren’t. Some of LLVM’s new clients, like WebKit, are embedding LLVM into existing applications. These embedded uses of LLVM have their own unique

Hello! I'm using LLVM's JIT in my project. Is there any way to view assembly code of functions it generates without disassembling them from the memory?

> (7) Make the C API truly great. > > I think it’s harmful to LLVM in the long run if external embedders use the C++ API. I think that one way of ensuring that they don’t have an excuse to do it is to flesh out some things: > > - Add more tests of the C API to ensure that people don’t break it accidentally and to give more gravitas to the C API backwards compatibility claims. >

On Tue, Aug 5, 2014 at 2:49 PM, Filip Pizlo <fpizlo at apple.com> wrote: > >> On Aug 5, 2014, at 1:46 PM, Eric Christopher <echristo at gmail.com> wrote: >> >>> (7) Make the C API truly great. >>> >>> I think it’s harmful to LLVM in the long run if external embedders use the C++ API. I think that one way of ensuring that they don’t have an

On Sun, Aug 10, 2014 at 1:43 PM, Filip Pizlo <fpizlo at apple.com> wrote: > I think this ignores the real problem with the MCJIT debugging interface: it doesn't give MCJIT clients any way of directly accessing and parsing the debug metadata. > Parsing the existing debug metadata isn't necessarily a good idea anyhow. It's not a stable format and is quite large. >

On Tue, Aug 5, 2014 at 2:57 PM, Filip Pizlo <fpizlo at apple.com> wrote: > > On Aug 5, 2014, at 2:51 PM, Eric Christopher <echristo at gmail.com> wrote: > > On Tue, Aug 5, 2014 at 2:49 PM, Filip Pizlo <fpizlo at apple.com> wrote: > > > On Aug 5, 2014, at 1:46 PM, Eric Christopher <echristo at gmail.com> wrote: > > (7) Make the C API truly great.

Filip Pizlo wrote: > This is exciting! > > I would be happy to help. > > >> On Aug 5, 2014, at 12:38 PM, Chris Bieneman<beanz at apple.com> wrote: >> >> Hello LLVM community, >> >> Over the last few years the LLVM team here at Apple and development teams elsewhere have been busily working on finding new and interesting uses for LLVM. Some of

Below is an outline of various usage models for MCJIT that I put together based on conversations at last month's LLVM Developer Meeting. If you're using or thinking about using MCJIT and your use case doesn't seem to fit in one of the categories below then either I didn't talk to you or I didn't understand what you're doing. In any case, I'd like to see this get

Hi all, It is my understanding that now WebKit depends on the stack map functionality in production. Also, on the mailing lists we've seen lots of users using in this feature. Can we eliminate the experimental status for 3.5? Off the top of my head, the changes needed are: - A read-through of StackMaps.rst to remove any mention of it being experimental. - Removing mention of it being

On Dec 9, 2013, at 11:08 AM, Kaylor, Andrew <andrew.kaylor at intel.com> wrote: > Below is an outline of various usage models for MCJIT that I put together based on conversations at last month’s LLVM Developer Meeting. If you’re using or thinking about using MCJIT and your use case doesn’t seem to fit in one of the categories below then either I didn’t talk to you or I didn’t understand

Hi All, I'd like to revisit the MCJIT debugger-registration system, as the existing system has a few flaws, some of which are seriously problematic. The 20,000 foot overview of the existing scheme (implemented in llvm/lib/ExecutionEngine/RuntimeDyld/GDBRegistrar.cpp and friends), as I understand it, is as follows: We have two symbols in MCJIT that act as fixed points for the debugger to

Hi Andy, My use case is quite similar to what Keno described. I am using clang + JIT to dynamically compile C++ functions generated in response to user interaction. Generated functions may be unloaded or modified. I would like to break down the old JIT code into three major parts. 1) The old JIT has its own code emitter, which duplicates code from lib/MC and does not generate debug info and

With Julia, we're obviously very much in the first use case. As you know, we pretty much have a working version of Julia on top of MCJIT, but there's still a few kinks to work out, which I'll talk about in a separate email. One think which I remember you asking at the BOF is what MCJIT currently can't do well that the old JIT did, so I'd like to offer up an example. With the