similar to: JIT stack trace

I am following up on an earlier conversation here with respect to jit stack traces. Any thing changed here with respect to latest llvm versions.. On Wed, Nov 13, 2013 at 08:51 AM, Reid Kleckner <rnk at google.com

On Mar 29, 2009, at 5:31 PM, Evan Cheng wrote: > > On Mar 29, 2009, at 9:48 AM, Kasra wrote: > >> >> Hi guys, >> >> I was looking arround Firefox 3.1 js JIT (TraceMonkey), it made me >> wonder if there is anyone working on a trace-tree technique for >> optimising the runtime over head of LLVM JIT?? >> > >LLVM directly supports this sort of

Writing your own JITEventListener is probably the best way to capture traces from production. Using the existing gdb/JIT interface support is probably far too heavyweight for production. If you roll your own, you can record the PC ranges efficiently and that should be good enough to capture traces from production. On Tue, Nov 12, 2013 at 2:56 PM, Priyendra Deshwal <deshwal at

>From NotifyObjectEmitted you should be able to get to any function that's visible via either the ELF headers or the DWARF information. Do you have functions that don't show up in either of those places? -Andy From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Andrew MacPherson Sent: Wednesday, November 13, 2013 9:23 AM To: Reid Kleckner Cc:

Hey guys, In our project we have the following workflow: - Given a user request, we construct a C++ program to service the request - We create a compiler invocation to compile that program into an IR module - We use JIT (and optionally MCJIT) to convert the IR into executable code and run it Occasionally, we have a crash in the JIT code and we are looking to figure out best practices around

Yeah, take a look at the IntelJITEventListener code (in lib/ExecutionEngine/IntelJITEvents). It uses the debug info to find function names. -Andy From: Andrew MacPherson [mailto:andrew.macp at gmail.com] Sent: Wednesday, November 13, 2013 1:12 PM To: Kaylor, Andrew Cc: Reid Kleckner; llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Stack traces from JIT code Hi Andy, In the NotifyObjectEmitted

[Resending this email after subscribing to the group. Got an error message the previous time around] Hey guys, In our project we have the following workflow: - Given a user request, we construct a C++ program to service the request - We create a compiler invocation to compile that program into an IR module - We use JIT (and optionally MCJIT) to convert the IR into executable code and run it

Hi guys, I was looking arround Firefox 3.1 js JIT (TraceMonkey), it made me wonder if there is anyone working on a trace-tree technique for optimising the runtime over head of LLVM JIT?? ---------------------------------------------------------------- With Best Regards Mr. Kasra Nassiri Department of Mathematics & Computer Science Imperial College London

No. I am not aware of any/ Evan On Mar 29, 2009, at 9:48 AM, Kasra wrote: > > Hi guys, > > I was looking arround Firefox 3.1 js JIT (TraceMonkey), it made me > wonder if there is anyone working on a trace-tree technique for > optimising the runtime over head of LLVM JIT?? > > ---------------------------------------------------------------- > With Best Regards >

>Only compile to LLVM IR the pieces of the code that are hot. Cold >pieces just run through the interpreter. Falling off the trace tree >returns to the interpreter. Chaining of traces can be done by having >traces end with indirect tail calls. Sounds like a plan. I don't suppose anyone is working on this, righ? I thought we could have a flag in the LLVM IR that could

Hi Andy, In the NotifyObjectEmitted method of our derived JITEventListener class we use the begin_symbol() iterator to walk the object's symbols looking for functions and only functions marked with ExternalLinkage seem to show up. I'm not sure how I would access the Dwarf info from within there, is there a way? Thanks, Andrew On Wed, Nov 13, 2013 at 8:23 PM, Kaylor, Andrew

We implemented a similar solution for handling crashes in production but one issue we came across with MCJIT was that the NotifyFunctionEmitted call from the old JIT was replaced with NotifyObjectEmitted. The ObjectImage used by NotifyObjectEmitted does have a way of iterating symbols but non-external functions used in the module didn't seem to appear in this list so we were left with some

yeah i m concerned about jit compilation time.. On Sun, Jun 30, 2019 at 12:57 PM Praveen Velliengiri < praveenvelliengiri at gmail.com> wrote: > Yes I think so.. Could you please tell me in which context (compile time > improvement)? That is whether you are interested in knowing whether having > ORC instead of MCJIT, will increase your LLVM Build time or you are > concerned

This is https://bugs.llvm.org/show_bug.cgi?id=24233. I don't think there's been any movement on it for a while. I don't *think* it should be hard, but I've never really pushed on it. On Tue, Jan 2, 2018 at 3:57 PM, Jason via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Hi, I use LLVM MCJIT extensively and one of the sore spots is debugging. > We lose stack

Hi, I use LLVM MCJIT extensively and one of the sore spots is debugging. We lose stack information if we crash during execution of one of our JIT functions. I spent some time to understand Windows x64 stack/exception handling and was able to hardcode support for a single JIT function and was able to maintain the call stack correctly. However it requires knowledge of the prolog of the function to

Hi, I'm using LLVM/clang from release 3.0. I have a program (C++) that will load a library in the form of LLVM bit code using the JIT. However, I see JIT errors when loading the bit code: "LLVM ERROR: JIT does not support inline asm" I read that MC JIT intends to fix this. I'm trying to build LLVM from the lastest trunk. Is there any special/extra thing to do to use

Here is what I did: I took c.C (attached), compiled it into my.ll code with command 'clang++ -O3 -fexceptions -emit-llvm -S -o my.ll c.C' and added tracing command on every line, see attached my.ll Running my.ll in interpreter with this command 'llvm-as my.ll && lli -jit-enable-eh my.bc', I get this log: TRACE num=20 TRACE num=22 TRACE num=27 TRACE num=29 TRACE num=31

Hi Yuri, > I get SEGV in gcc-compiled procedure in Solaris10-i386. This procedure > is called from llvm JIT code. > Exact instruction that crashes is this: movdqa %xmm0, 0x10(%esp) > %esp is 8-aligned, and by definition of movdqa it expects 16-aligned stack. > This leads me to believe that llvm uses wrong ABI when calling external > procedures and doesn't align stack

On 02/20/2011 23:50, Duncan Sands wrote: > Hi Yuri, > > >> I get SEGV in gcc-compiled procedure in Solaris10-i386. This procedure >> is called from llvm JIT code. >> Exact instruction that crashes is this: movdqa %xmm0, 0x10(%esp) >> %esp is 8-aligned, and by definition of movdqa it expects 16-aligned stack. >> This leads me to believe that llvm uses

> Hi, > I'm using LLVM/clang from release 3.0. I have a program (C++) that will load > a library in the form of LLVM bit code using the JIT. However, I see JIT errors > when loading the bit code: > > "LLVM ERROR: JIT does not support inline asm" > > I read that MC JIT intends to fix this. I'm trying to build LLVM from the > lastest trunk. Is