search for: lazili

TL;DR - when linking from a lazily loaded module and using Linker::LinkOnlyNeeded, bodies of used functions aren't being copied during linking. Previously on one of our products, we would lazily load our runtime module (around 9000 functions), and link some user module into this (which is in all practical use cases much smaller). Then, post linking, we have a pass that runs over the

+cc Artem, who added the LinkOnlyNeeded flag. On Wed, Apr 20, 2016 at 9:18 AM, Mehdi Amini via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi Neil, > > On Apr 20, 2016, at 5:20 AM, Neil Henning via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > TL;DR - when linking from a lazily loaded module and using > Linker::LinkOnlyNeeded, bodies of used functions

Hey all, For LinkModules, /*dest*/ is a fully materialized module, /*src*/ is a lazily loaded module. From what I understood, getLinkedToGlobal() is finding the function in /*src*/ that matches some function declaration in /*dest*/, and given that /*src*/ is lazily loaded it could be un-materialized. The functions I need brought in from /*src*//**/ into /*dest*/ are always declarations in

Hi, I'm trying to port some code from the original JIT (a project I haven't had a chance to work on for quite a while) to the new Orc JIT. I thought I'd try to use the Kaleidoscope tutorial as a starting point for getting acquainted with the new JIT and so I first tried to add the ability to load an existing bitcode file, then make calls to functions from that file. That was easy to

> > > I understood from his description that he reversed the destination and > source so that destination is the user code. > I assumed it was not lazy loaded, but that would explain the question then > :) > > Neil: can you clarify? If Teresa is right, why aren't you materializing > the destination module entirely? > > I don't think it has ever been tried

Hello, As the title line says, I'm getting assertions on recursive JIT compiation, like this: opt: JIT.cpp:627: void llvm::JIT::runJITOnFunctionUnlocked(llvm::Function*, const llvm::MutexGuard&): Assertion `!isAlreadyCodeGenerating && "Error: Recursive compilation detected!"' failed. 0 libLLVM-2.7.so 0x012eb2c8 Stack dump: 0. Program arguments: opt

On Jul 4, 2009, at 5:59 AM, Carter Cheng wrote: > I have tracing the calls to materializeFunction in the LLVM code in > hopes of determining how to properly utilize this function but from > my explorations I gather it's just a hook which is called by the JIT > system and I would mostly have to do the work myself. ModuleProvider is a very simple concept. You can either load

On Dec 7, 2012, at 11:51 AM, Shankar Easwaran wrote: > We have few symbols like __bss_start, __bss_end, which are Undefined symbols in the code. > > I want a way in the Reader to create specific atoms before the linker bootstraps. > > I didnt find a way to do that with the existing interfaces. > > The way it needs to work is as below :- > > 1) ReaderELF creates

Chris Lattner wrote: > > I don't think this is really the right way to go. Can you give an > example snippet of Java code that would need this and what you are > proposing? With a concrete example that shows how the lazy class > loading stuff works we can talk about different possibilities, > > Field operations in Java (getfield, putfield, getstatic, putstatic)

>>>>> "Chris" == Chris Lattner <sabre at nondot.org> writes: >> FWIW I actually did this work twice, once for libjit and once for >> LLVM. I'm happy to provide a comparison, from a jit-writing >> perspective, if you're interested. Chris> Given your experience with both, I'd be very interested in any Chris> thoughts you have on

Hi Nick, We have few symbols like __bss_start, __bss_end, which are Undefined symbols in the code. I want a way in the Reader to create specific atoms before the linker bootstraps. I didnt find a way to do that with the existing interfaces. The way it needs to work is as below :- 1) ReaderELF creates Absolute symbols (for __bss_start, __bss_end etc) 2) ReaderELF reads each file and adds

On Wed, Oct 26, 2016 at 2:04 PM, Peter Collingbourne via llvm-dev <llvm-dev at lists.llvm.org> wrote: > On Tue, Oct 25, 2016 at 8:36 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: >> >> >> On Oct 25, 2016, at 6:28 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: >> >> Hi all, >> >> As mentioned in my recent RFC entitled

On Tue, Oct 25, 2016 at 8:36 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > On Oct 25, 2016, at 6:28 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > > Hi all, > > As mentioned in my recent RFC entitled "RFC: a more detailed design for > ThinLTO + vcall CFI" I would like to introduce the ability for bitcode > files to contain multiple

Thanks for the reply. I actually managed to resolve this problem mostly to my satisfaction. I suspect based on your description of materializeFunction I may be best served by subclassing the ModuleProvider to do what I want. Thanks again. --- On Mon, 7/6/09, Chris Lattner <clattner at apple.com> wrote: > From: Chris Lattner <clattner at apple.com> > Subject: Re: [LLVMdev]

On Tue, 6 Nov 2007, Nicolas Geoffray wrote: > Field operations in Java (getfield, putfield, getstatic, putstatic) do > _not_ need what I'm proposing. What I'm proposing is just performance > related (just like method patching in callbacks is an optimization in > order to not call the callback everytime). > > Here's a simple example: consider class One: > >

Chris Lattner wrote: > On Wed, 18 May 2005, Chris Lattner wrote: > >> Yup, something like this should work. Two comments though: >> 2. I haven't done much testing with the JIT and tail calls. I >> wouldn't be >> suprised if there are minor issues that need to be fixed. I will try >> to take a look and see what remains to be done over the next

I have tracing the calls to materializeFunction in the LLVM code in hopes of determining how to properly utilize this function but from my explorations I gather it's just a hook which is called by the JIT system and I would mostly have to do the work myself. What is the preferred way to inject a llvm:Function which contains basic blocks into the Module + JIT? My understanding (perhaps

Hi Nick, On 12/7/2012 4:59 PM, Nick Kledzik wrote: > > We have a similar requirement in darwin's ld64 linker, but even more general. Any binary can do the following to introspect itself: > > struct stuff { int a; int b; }; > > extern struct stuff* stuff_start __asm("section$start$__DATA$__my"); > extern struct stuff* stuff_end

On Fri, Oct 28, 2016 at 6:11 AM, Will Dietz <willdtz at gmail.com> wrote: > On Wed, Oct 26, 2016 at 2:04 PM, Peter Collingbourne via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > On Tue, Oct 25, 2016 at 8:36 PM, Mehdi Amini <mehdi.amini at apple.com> > wrote: > >> > >> > >> On Oct 25, 2016, at 6:28 PM, Peter Collingbourne <peter