similar to: [LLVMdev] MC-JIT Patches 3/3

Displaying 20 results from an estimated 40000 matches similar to: "[LLVMdev] MC-JIT Patches 3/3"

2010 Jul 28
2
[LLVMdev] MC-JIT Patches 2/3
This patch contains the initial implementation of MCJIT. - Jan -------------- next part -------------- A non-text attachment was scrubbed... Name: 0019_mcjit.patch Type: text/x-diff Size: 42198 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100728/2eb6ac65/attachment.patch>
2010 Jul 28
2
[LLVMdev] MC-JIT Patches 1/3
I have cleaned up the code somewhat that Olivier wrote and split up the patch into three pieces. This first is to make the MCJIT not have to initialize all asm printers, but only the native one. - Jan -------------- next part -------------- A non-text attachment was scrubbed... Name: 0018_nativeasmprinterinit.patch Type: text/x-diff Size: 12993 bytes Desc: not available URL:
2010 Aug 01
0
[LLVMdev] MC-JIT Patches 2/3
Hi Jan, I would rather not work with a patch this large. Can you pull out the addition of the MCJITStreamer into its own patch, and we can iterate on getting that in as a single commit? I realize it won't work or do anything useful, but I can't deal with reviewing patches this large. The main thing I am concerned about is getting the basic design of how the streamer and the assembler and
2010 Aug 01
0
[LLVMdev] MC-JIT Patches 1/3
Hi Jan, Applied with edits in r109996, thanks! I wasn't happy about the change to add "Target" everywhere -- I just added a local hack in TargetSelect.h to workaround this. We should really change the definition of LLVM_NATIVE_TARGET, but I am not in a configure hacking mood. - Daniel On Wed, Jul 28, 2010 at 10:39 AM, Jan Sjodin <jan_sjodin at yahoo.com> wrote: > I have
2010 Jul 19
7
[LLVMdev] MC-JIT
Together with Jan Sjodin (in copy of this email), we begin an implementation of the JIT with MC. The idea, suggested by Jan, is to develop a MCJIT in parallel of the current JIT and to keep the two implementations until (at least) the new MC one is mature enough. Currently code is kept on gitorious (http://gitorious.org/llvm-mc-jit/llvm-mc-jit). Following this, a boolean "bool MCJIT =
2010 Jul 20
0
[LLVMdev] MC-JIT
Some boring style comments: - whack trailing whitespace - spaces, not tabs - the methods in MCJITStreamer.cpp should probably have blank lines between them There seems to be an ownership problem of the MCJITObjectWriter. If I understand the code correctly, the assembler Finish method takes ownership of the Writer parameter, which presumably is needed to JIT two functions. +1 for separate
2010 Jul 20
2
[LLVMdev] MC-JIT
> In the context of the JIT, there really is no such thing as a > relocation, just fixups. I'm not completely sure what the right > approach is, but the JIT should be able to fully resolve all of the > symbols that are being used in the module. We may need some extra > interfaces to allow the JIT to tell the MCAssembler about the address > of some external symbols though.
2011 Aug 31
0
[LLVMdev] Trouble using the MCJIT: "Target does not support MC emission" error
Hi Matt, hi Bruno, I am still struggling to use AVX via MCJIT on TOT... did you succeed yet? I seem to be unable to even get lli to run some code with the "use-mcjit" flag. I attached a test case that works fine for "lli y.bc" but exits with an error for "lli -use-mcjit y.bc": "LLVM ERROR: Unknown object format" If I call InitializeAllTargetMCs() before
2011 Jun 24
1
[LLVMdev] MC-JIT (any progress?)
On 07/19/2010 05:14, Olivier Meurant wrote: > Together with Jan Sjodin (in copy of this email), we begin an > implementation of the JIT with MC. The idea, suggested by Jan, is to > develop a MCJIT in parallel of the current JIT and to keep the two > implementations until (at least) the new MC one is mature enough. > Currently code is kept on gitorious >
2011 Aug 31
1
[LLVMdev] Trouble using the MCJIT: "Target does not support MC emission" error
ons 2011-08-31 klockan 10:51 +0200 skrev Ralf Karrenberg: > Hi Matt, hi Bruno, > > I am still struggling to use AVX via MCJIT on TOT... did you succeed yet? > > I seem to be unable to even get lli to run some code with the > "use-mcjit" flag. > I attached a test case that works fine for "lli y.bc" but exits with an > error for "lli -use-mcjit
2012 May 08
0
[LLVMdev] JIT support for inline asm on Linux
> On 5/7/2012 12:21 AM, Bendersky, Eli wrote: > <snip> > > > > MCJIT is functional in trunk (and the 3.1 branch). While it doesn't include all > the features of the old JIT quite yet, it's complete enough to pass all of JIT's > execution tests on Linux and Mac OS X (no Windows yet). As for directions > on how to enable it, follow the path of the
2012 May 07
2
[LLVMdev] JIT support for inline asm on Linux
On 5/7/2012 12:21 AM, Bendersky, Eli wrote: <snip> > > MCJIT is functional in trunk (and the 3.1 branch). While it doesn't include all the features of the old JIT quite yet, it's complete enough to pass all of JIT's execution tests on Linux and Mac OS X (no Windows yet). As for directions on how to enable it, follow the path of the "use-mcjit" flag passed to lli
2010 Sep 01
0
[LLVMdev] MC-JIT Streamer 1/3
I cleaned up the indentation in the three patches and attached them. Please let me know if there are other issues. The patches should all apply cleanly with the latest revision. I will wait with submitting more patches until the MCJITSTreamer has been reviewed and checked in. Thanks, Jan --- On Sat, 8/21/10, Bruno Cardoso Lopes <bruno.cardoso at gmail.com> wrote: From: Bruno Cardoso
2011 Jun 24
0
[LLVMdev] MC-JIT (any progress?)
On Jun 24, 2011, at 12:44 PM, Yuri wrote: > On 07/19/2010 05:14, Olivier Meurant wrote: >> Together with Jan Sjodin (in copy of this email), we begin an >> implementation of the JIT with MC. The idea, suggested by Jan, is to >> develop a MCJIT in parallel of the current JIT and to keep the two >> implementations until (at least) the new MC one is mature enough. >>
2012 May 08
2
[LLVMdev] JIT support for inline asm on Linux
On 5/7/2012 10:17 PM, Bendersky, Eli wrote: <snip> >>> $lli -entry-function="ISimEngine_GetVersion" -use-mcjit libengine.bc >>> LLVM ERROR: Inline asm not supported by this streamer because we don't >>> have an asm parser for this target >> >> I also tried other variations of the call with the same result: >>> $lli
2012 May 09
0
[LLVMdev] JIT support for inline asm on Linux
Resending, any pointers are much appreciated. On 5/7/2012 11:16 PM, Ashok Nalkund wrote: > > > On 5/7/2012 10:17 PM, Bendersky, Eli wrote: > <snip> >>>> $lli -entry-function="ISimEngine_GetVersion" -use-mcjit libengine.bc >>>> LLVM ERROR: Inline asm not supported by this streamer because we don't >>>> have an asm parser for this
2012 May 07
0
[LLVMdev] JIT support for inline asm on Linux
> 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
2010 Aug 20
1
[LLVMdev] MC-JIT Streamer 1/3
I was delayed creating the smaller patches, but finally I had some time to put the first set together. There are three small patches, the first two are classes the MCJITStreamer uses, and the last patch is the MCJITStreamer class itself. - Jan --- On Sun, 8/1/10, Daniel Dunbar <daniel at zuster.org> wrote: > From: Daniel Dunbar <daniel at zuster.org> > Subject: Re: [LLVMdev]
2012 Jul 31
1
[LLVMdev] Help with PPC64 JIT
On 07/31/2012 11:26 AM, Adhemerval Zanella wrote: > On 07/20/2012 10:35 AM, Will Schmidt wrote: >> On Fri, 2012-07-20 at 08:36 +0200, Duncan Sands wrote: >>> Hi Adhemerval Zanella, the old JIT infrastructure is going away, to be replaced >>> by "MC-JIT" (try passing -use-mcjit to lli). It sounds like you are working on >>> the old JIT, so I suggest
2011 Aug 26
2
[LLVMdev] Trouble using the MCJIT: "Target does not support MC emission" error
Following along from lli code, if you add a call to InitializeNativeTargetAsmPrinter() during setup, it gets a bit farther and crashes rather than issuing that error. (Rebuilding with debugging symbols now to dig into it further…) -matt Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000 0x000000010000349e in