similar to: [LLVMdev] Disabling some JIT optimization?

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"

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

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:

On 06/23/2016 12:56 PM, Craig Topper wrote: > Can you check what value "getHostCPUName" returned? getHostCPUName() = skylake > > On Thu, Jun 23, 2016 at 9:53 AM, Frank Winter via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > With LLVM 3.8 the JIT compiler engine generates an AVX512 > instruction although I

We don't currently apply any relocations (that I know of) for debug info in LLDB. > On Jun 2, 2014, at 12:35 PM, Keno Fischer <kfischer at college.harvard.edu> wrote: > > I think I'm getting closer. The debug_info section is being relocated correctly (I think): > > 0x00000000: Compile Unit: length = 0x00000045 version = 0x0003 abbr_offset = 0x00000000 addr_size =

I didn't get to work on this more last week, but I'll look at incorporating that suggestion. The other question of course is how to do this in LLDB. Right, now what I'm doing is going through and adjusting the load address of every leaf in the section tree. That basically works and gets me backtraces with the correct function names and the ability to set breakpoints at functions in

Le 18 juil. 2013 à 19:07, Eli Friedman <eli.friedman at gmail.com> a écrit : > On Thu, Jul 18, 2013 at 9:07 AM, Stéphane Letz <letz at grame.fr> wrote: >> Hi, >> >> Our DSL LLVM IR emitted code (optimized with -O3 kind of IR ==> IR passes) runs slower when executed with the LLVM 3.3 JIT, compared to what we had with LLVM 3.1. What could be the reason? >>

Hello, Am I right in thinking that MCJIT doesn't support thread-local variables (at least not on Linux x86-64)? Is there any plan or pending PR to support it (either in MCJIT or in ORC)? Thank you, Regards Antoine.

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

When using ORC JIT, I'm having trouble with external function resolution (that is, of a function defined in the app, with C linkage). I add a declaration for the function to my IR, and when I use MCJIT, it finds it and all is well, But when I use ORC JIT (I *think* correctly, at least it closely matches what I see in the tutorial), I get an LLVM error, "Program used external function

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

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

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

Currently it appears X86WrapperRIP is only implemented in the small code model, which causes code to fail to select in other code models. My particular use case is MCJIT, where the default code model is large (the X86WrapperRIP comes from a TLS variable reference). What would be the best way to implement this? I'd be happy to take a crack at it myself, but I really don't know my way around

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

Yes, it would be great to get that fixed. On Wed, Feb 5, 2014 at 4:09 PM, Evgeniy Stepanov <eugeni.stepanov at gmail.com>wrote: > On Thu, Feb 6, 2014 at 12:21 AM, Keno Fischer > <kfischer at college.harvard.edu> wrote: > > Looks like when you materialize the stores, you should check the size of > the > > the store and emit an appropriate amount of stores to the

I have verified that both TLS implementations indeed find the same area of memory. Anything else I could look for? On Tue, Jan 28, 2014 at 4:28 PM, Keno Fischer <kfischer at college.harvard.edu>wrote: > Yes, both JIT code and the native runtime are instrumented. I am under the > impressions that the the C library should guarantee that from the way the > relocations are