similar to: MCJit Runtine Performance

----- Original Message ----- > From: "Keno Fischer via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Morten Brodersen" <Morten.Brodersen at constrainttec.com> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Thursday, February 4, 2016 6:05:29 PM > Subject: Re: [llvm-dev] MCJit Runtine Performance > > > > Yes,

Hi Keno, Thanks for the fast ISel suggestion. Here are the results (for a small but representational run): LLVM 3.5.2 (old JIT): 4m44s LLVM 3.7.1 (MCJit) no fast ISel: 7m31s LLVM 3.7.1 (MCJit) fast ISel: 7m39s So not much of a difference unfortunately. On 05/02/16 11:05, Keno Fischer wrote: > Yes, unfortunately, this is very much known. Over in the julia > project, we've recently

Hi Lang, > That suggests an optimization quality issue, rather than compile-time overhead Yes that makes sense. The long running applications (6+ hours) JIT the rules once (taking a few seconds) and then run the generated machine code for hours. With no additional JIT'ing. > if we can configure the CodeGen pipeline properly we can get the performance back to the same level as

Hi Lang, > MCJIT does not compile lazily (though it sounds like that's not an issue here?) That is not an issue here since the code JIT's once (a few secs) and then run the generated machine code for hours. > Morten - Can you share any test cases that demonstrate the slowdown. I'd love to take a look at this. The code is massive so not practical. However I will try and

Can you build the code with llc? Try with the large code model. I think that is the default for MCJIT and can be less efficient. Cheers, Rafael On 4 February 2016 at 22:26, Morten Brodersen via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Hi Hal, > > We are using the default register allocator. I assume the greedy one is > default? > > As for other target machine

Hi Morten, Something else just occurred to me: can you share your EngineBuilder configuration lines? (http://llvm.org/docs/doxygen/html/classllvm_1_1EngineBuilder.html) In particular - are you explicitly setting the optimization level? The old JIT may have had a different default. - Lang. Sent from my iPad > On Feb 4, 2016, at 10:54 PM, Jim Grosbach via llvm-dev <llvm-dev at

Hi Keno, I am talking about runtime. The performance of the generated machine code. Not the time it takes to lower the IR to machine code. We typically only JIT once (taking a few secs) and then run the generated machine code for hours. So the JIT time (IR -> machine code) doesn't impact us. Cheers Morten On 05/02/16 15:58, Keno Fischer wrote: > Actually, reading over all of this

On 4 February 2016 at 22:48, Morten Brodersen via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Hi Rafael, > > Not easily (llc). > > Is there a way to make MCJit not use the large code model when JIT'ing? > I think Davide started adding support for the small code model. Cheers, Rafael

Hi Keno, The part that scares me a bit is > and then adjust the other methods to not > bail out two quickly when encountering a weak symbol. I would very much appreciate if you could implement this; I don't have enough knowledge of the MCJIT nor llvm CodeGen internals... I will happily try it out and provide you with feedback, though! :-) Thank you *so* much for your fast reaction!

Hi Keno, Could you give a short high-level overview of the way Julia works now with MCJIT instead the JIT: What I gather so far... * Compiled IR functions are emitted to a shadow module. * Any used function is cloned into its own new module and the module is added to MCJIT. * Called functions or globalvars are only declared in that module. * Modules are never removed meaning "old"

On 22 May 2013 12:30, Kaylor, Andrew <andrew.kaylor at intel.com> wrote: > To clarify, MCJIT currently has no GOT support whatsoever for ELF with x86-64 and ARM (and probably others). No, I added a bare minimal to get EH working... > My experimental patch was meant as an attempt to get TLS working with static relocation model and small code model. It's the combination of these

Hi Everyone, If you're JITing with LLVM and haven't made the switch to MCJIT already, now is the time. As per discussions on the mailing list and at the last dev meeting, LLVM 3.5 will be the last release to support the old JIT infrastructure. Now that LLVM 3.5 has branched, we plan to start removing the old JIT from the mainline. If you're looking for help in making the switch, Andy

Hi, I'm finally moving cling to MCJIT - and MCJIT is wonderful! So far I only ran into this issue: $ cat linkonceodr.cxx extern "C" int printf(const char*,...); template <class T> struct StaticStuff { static T s_data; }; template <class T> T StaticStuff<T>::s_data = 42; int compareAddr(int* mcjit); #ifdef BUILD_SHARED int compareAddr(int* mcjit) { if (mcjit

Hi Dale, I don't think that Keno's rewrite is applicable for a bug fix release. We have, in the last year, moved to having some dot releases for our older releases, but these are definitely bug fix only and low risk as we don't want to break anything new. The release documentation is located here: http://llvm.org/docs/HowToReleaseLLVM.html for future reference. There's no

On Fri, May 22, 2015 at 4:14 PM, Keno Fischer <kfischer at college.harvard.edu> wrote: > This might be related to GOT relocations. I rewrote that part of > RuntimeDyldELFbecause I was seeing this issue. Have you tried trunk? > I didn't notice that you were running 3.5 the first time I read this. Keno's diagnosis is very likely to be correct. You should try trunk if

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

Hello everyone, As part of my quest to add TLS relocation support to MCJIT, I've been taking a closer look at the GOT implementation in RuntimeDyldELF and I believe that is not valid as currently implemented. In particular, I am wondering about the multiple GOT handling support introduced in r192020. If I understand correctly this can make code reuse the GOT table entry in a different object

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

So it appears that we get about half the crashes with the large code model. The rest are crashing in the same way. It could either mean that large code model still takes that crashing codepath and that the number of crashes only went down by chance, or that in one place in the flow, large code model is not matched to mean ELF::R_X86_64_PC64. I'm digging into this issue further, but any hints

Hello, I'm finally getting back to getting JIT debugging work for MCJIT. This has worked for ELF for a while in LLVM and support in lldb was added in January (for ELF). I'm now trying to add support for Mach-O and would appreciate some feedback (though I'm fighting my way through learning the format, I'm still just a novice). My current patchset for llvm is here: