similar to: [LLVMdev] [Code ownership] MCJIT

I'll +1 this, his code and design have both been great. -eric On Fri, Nov 16, 2012 at 11:27 AM, Jim Grosbach <grosbach at apple.com> wrote: > All, > > I'd like to suggest Andy Kaylor take official ownership of the MCJIT. He's > done a fantastic job already of improving it and wrangling lots of patch > submissions for it. This seems the logical next step to me.

On Fri, Nov 16, 2012 at 11:45 AM, Eric Christopher <echristo at gmail.com> wrote: > I'll +1 this, his code and design have both been great. > > -eric > > > On Fri, Nov 16, 2012 at 11:27 AM, Jim Grosbach <grosbach at apple.com> wrote: >> >> All, >> >> I'd like to suggest Andy Kaylor take official ownership of the MCJIT. He's >>

I don’t follow. Why are we looking at the module at all? That query should work even (especially) after the Module is deleted. We should be able to have a local symbol table that’s a DenseMap or something similar to resolve from names to target addresses. That map would be updated as part of the compilation when the object’s symbol table gets read. -Jim On Oct 21, 2013, at 4:55 PM, Kaylor,

Andrew, I've attached a small reproduction of the issue. Reproduce by: $ /usr/bin/g++ `llvm-config --cxxflags` -g -m32 -c mcjit_external_symbol.cpp $ /usr/bin/g++ `llvm-config --ldflags` -g -m32 -o mcjit_external_symbol mcjit_external_symbol.o `llvm-config --libs all` $ ./mcjit_external_symbol verifying... LLVM ERROR: Program used external function '_external' which could not be

Thanks, Eran. I’m not sure how soon I’ll have a solution for you, but it’s on my to-do list now. I’ll also create a bugzilla record for this problem. -Andy From: Weiss, Eran [mailto:Eran.Weiss at emc.com] Sent: Thursday, April 11, 2013 12:40 AM To: Kaylor, Andrew Cc: llvmdev at cs.uiuc.edu; Jim Grosbach; Jiong Wang Subject: Re: [LLVMdev] Migration from JIT to MCJIT Andrew, I've attached

The search is linear? If that’s really true, we should fix that. On Oct 21, 2013, at 10:14 AM, Kaylor, Andrew <andrew.kaylor at intel.com> wrote: > I should have read this before sending my previous reply. :-) > > I’m not a big fan of default parameters, but some form of what you are suggesting may be useful. See my other comments on this topic in the other reply. > >

Existing clients (LLDB) deal with externals by resolving them to constant function pointers that are referenced in the IR. That’s obviously ugly as hell, but it gets things done. The old JIT was able to simplify things because it assumed the JITed code was running in the same process as the JIT compiler. The MCJIT doesn’t assume that, so it has to handle more possibilities. For example, that the

On Sep 4, 2012, at 5:23 PM, Jim Grosbach <grosbach at apple.com> wrote: > Chris, are you OK with the below changes to the Triple? If at all possible, I'd like to keep the triple changes separate (separate patch series and separate discussion) from the other MCJIT changes. How dependent are the MCJIT improvements on the Triple changes? As you've noticed, Triple is not a

Eran, Is there any chance you could boil this down to a small reproducer? I’ve got a mid-to-long-term goal of getting rid of the ugliness in LLDB that Jim mentioned, and fixing your problem would be a good first step. Thanks, Andy From: Jim Grosbach [mailto:grosbach at apple.com] Sent: Wednesday, April 10, 2013 4:19 PM To: Kaylor, Andrew; Jiong Wang Cc: Weiss, Eran; llvmdev at cs.uiuc.edu

Hi Jim, Clearly searching for name should not be linear in modules but with a map of some kind. After compilation to IR each module has a StringMap symbol table. After compiling to MC and loading the object file, the dynamic linker has a StringMap symbol table for all loaded modules. In the usual use case you'll load module(s) into MCJIT and then compile / link them and all is well, no

Hi all, I'd like to propose that Lang Hames be made code owner of the MCJIT, RuntimeDyld and JIT event listener components. For those who don't know, I am the current code owner, but I have not had the time recently to make the level of contributions I had in the past while Lang has been doing outstanding work in this area and has taken on a de facto leadership role in guiding MCJIT

ping From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Kaylor, Andrew Sent: Tuesday, August 28, 2012 11:10 AM To: Jim Grosbach; Pawel Bylica; Chris Lattner Cc: llvmdev at cs.uiuc.edu (LLVMdev at cs.uiuc.edu) Subject: Re: [LLVMdev] RFC: MCJIT enhancements Has anything more happened with this? -Andy From: Jim Grosbach [mailto:grosbach at apple.com] Sent:

There's probably a lot that we could do, but I can't think of anything easy. Basically every time we need to look up a symbol by name we're going to each module and saying "Do you have this symbol?" It would likely be much better if we grabbed the function names from the module and did the search ourselves so that we could keep some information about the things that

Chris, are you OK with the below changes to the Triple? -Jim On Sep 4, 2012, at 5:21 PM, "Kaylor, Andrew" <andrew.kaylor at intel.com> wrote: > ping > > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Kaylor, Andrew > Sent: Tuesday, August 28, 2012 11:10 AM > To: Jim Grosbach; Pawel Bylica; Chris Lattner > Cc: llvmdev

Hi Andy, Sounds good in general. One question below: On Tue, Sep 17, 2013 at 4:01 PM, Kaylor, Andrew <andrew.kaylor at intel.com>wrote: > I'm about to start working on multiple module support in MCJIT. I know a > lot of people are interested in this so it seemed like a good idea to begin > by soliciting input. > > My immediate plan involves the following: > > -

I'm about to start working on multiple module support in MCJIT. I know a lot of people are interested in this so it seemed like a good idea to begin by soliciting input. My immediate plan involves the following: - Add something to the MCJIT interface to explicitly request module compilation - Isolate module-specific state variables into a structure so that the state of each module can be

On Aug 17, 2012, at 2:50 AM, Paweł Bylica <pawel.bylica at ibs.org.pl> wrote: > On Fri, Aug 17, 2012 at 12:16 AM, Kaylor, Andrew <andrew.kaylor at intel.com> wrote: > Hi Paweł, > > > > Thanks for continuing this discussion. > > > > I like the simplicity of your suggestion. My only concern involves the ambiguity of what is meant by “environment”.

Has anything more happened with this? -Andy From: Jim Grosbach [mailto:grosbach at apple.com] Sent: Friday, August 17, 2012 7:51 AM To: Paweł Bylica; Chris Lattner Cc: llvmdev at cs.uiuc.edu (LLVMdev at cs.uiuc.edu); Kaylor, Andrew Subject: Re: [LLVMdev] RFC: MCJIT enhancements On Aug 17, 2012, at 2:50 AM, Paweł Bylica <pawel.bylica at ibs.org.pl<mailto:pawel.bylica at ibs.org.pl>>

Hi, Can anyone tell me something about mmap and vm_protect on ARM+Apple systems? I'm working on a new memory manager implementation for MCJIT and I want to replace calls to Memory::AllocateRWX with calls to Memory::allocateMappedMemory, possibly still with the RWX flags. However, looking at the Memory::AllocateRWX implementation I see that it's jumping through some hoops in the case

The new MCJIT is module-oriented, like a classic compiler+linker (which it is) while the old JIT is function-oriented. If I understand correctly, the main problems with the old JIT were the duplication of the debug information code and EH code (both gone now). Moreover, if we ignore the lazy evaluation mechanism then the current JIT is actually quite simple module. Would it be possible to keep