similar to: [LLVMdev] Summer of Code 2009 "Support for an ELF writer"

Hi Chris, Just in case that this information does not get corrupted I want to point to the issue: In http://llvm.org/devmtg/2008-08/Geoffray_VMKitProject.pdf it is on page 21: "VMKit, Mono, PNet", Array bounds checks. In http://hal.inria.fr/docs/00/35/45/77/PDF/RR-6799.pdf it is on page 17: "We compare N3 with Mono [9] version 1.2.6, and PNet version 0.7.4 [2], which uses

Dear all, First, sorry for all that noise. I know you guys *just don't care*TM, but this requires some clarification. I won't say more than what's in this email. The VMKit paper dates from early 2008. It compares VMKit with pnet 0.7.4 and not the latest release (0.8.0) because we were not able to get any information to build it correctly at the time; the website that hosted

Hello Dear LLVM Developers and Users I would like to complain about scientific inaccuracy of the paper http://hal.inria.fr/docs/00/35/45/77/PDF/RR-6799.pdf written by Nicolas Geoffray, Gaël Thomas, Charles Clément, Bertil Folliot, Gilles Muller and presentation done by Nicolas Geoffray on LLVM conference supported by Google: http://llvm.org/devmtg/2008-08/Geoffray_VMKitProject.pdf They provide

On Mar 2, 2009, at 8:25 AM, Kirill Kononenko wrote: > Hello Dear LLVM Developers and Users Hi Kirill, Please talk to Nicholas about this, thanks! -Chris > > > I would like to complain about scientific inaccuracy of the paper > http://hal.inria.fr/docs/00/35/45/77/PDF/RR-6799.pdf written by > Nicolas Geoffray, Gaël Thomas, Charles Clément, Bertil Folliot, Gilles > Muller

Dear all, This new version of the paper at: http://hal.archives-ouvertes.fr/docs/00/36/53/37/PDF/RR-6799.pdf got ride of libJIT. Now my question is the how scientific is this research and research paper if instead of using libJIT and Portable.NET JIT: authors of "VMKit: a Substrate for Virtual Machines by Nicolas Geoffray — Gaël Thomas— Charles Clément —Bertil Folliot — Gilles

On Apr 20, 2009, at 12:42 PM, Kirill Kononenko wrote: > Dear all, > > > This new version of the paper at: > > http://hal.archives-ouvertes.fr/docs/00/36/53/37/PDF/RR-6799.pdf > > got ride of libJIT. Now my question is the how scientific is this > research and research paper if instead of using libJIT and > Portable.NET JIT: > authors of "VMKit: a Substrate

Hi Chris How does this has nothing to do with llvm? Is not the VMKit project an official part of LLVM? Thanks, Kirill -- http://code.google.com/p/libjit-linear-scan-register-allocator/

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

>>>>> "Jakob" == Jakob Praher <jp at hapra.at> writes: Jakob> I would definitely like to look into it. I'll send it in private email. Jakob> Yes very much! How did you find writing it directly in Jakob> SSA-form. Actually I used what Chris called "the alloca trick"... the JIT doesn't really generate SSA form but instead uses alloca to

hi Tom, I am really glad that someone has found time to step into that :-). Tom Tromey wrote: > I recently wrote an LLVM-based JIT plugin for libgcj and I thought > it'd be worthwhile to mention it here. > > It is in cvs on sourceforge, but afaics anonymous cvs there is pretty > broken at the moment... so if you want a copy, ask and I will email it > to you. wow. that is

On Tue, 18 Apr 2006, Tom Tromey wrote: > I recently wrote an LLVM-based JIT plugin for libgcj and I thought > it'd be worthwhile to mention it here. Cool! > Exception handling definitely does not work, I didn't even try to > implement it yet. I've been thinking about having some kind of simple > bridge between the LLVM and GCC worlds here -- very inefficient, but >

I recently wrote an LLVM-based JIT plugin for libgcj and I thought it'd be worthwhile to mention it here. It is in cvs on sourceforge, but afaics anonymous cvs there is pretty broken at the moment... so if you want a copy, ask and I will email it to you. Basically I hacked libgcj to (optionally) dynamically load JIT module at startup. If a JIT is loaded then bytecode is passed to it rather

Hi. I have more questions regarding llvm and using it as a jit for our purposes. Also, let me confess that I haven't actually used llvm yet (I'm still prototyping using gnu's libjit). Some of the issues that have come up from that work so far leads to me these questions: 1) We intend to use llvm as a jit in our expression compiler at compile-time only. At runtime, the x86 code

On Tue, Mar 23, 2010 at 4:44 PM, Shasank Chavan <shanko_chavano at hotmail.com> wrote: > Hi.  I have more questions regarding llvm and using it as a jit for our > purposes.  Also, let me confess that I haven't actually used llvm yet (I'm > still prototyping using gnu's libjit).  Some of the issues that have come up > from that work so far leads to me these questions:

Hi Reid. Thanks for your response. We will be running this code in different processes across different nodes. Basically we have thousands of "executor" processes that are solely responsible for executing this code generated at compile-time across partitioned data. Rather than each one of these processes invoking the jit and compiling with full opts and all of that, we believe it may

If you really trying to avoid linking everything into a shared library (easiest choice), consider splitting up the compilation into a few more steps: 1) Compile and optimize once as part of your build, target LLVM bitcode instead of machine code 2) Ship .bc files out to each node 3) Fix-up call instructions in a BasicBlockPass, run JIT without any/many additional IR optimizations enabled This

If you distribute the .bc to a new machine and JIT it there, you wouldn't need to apply any relocations to call instructions, since the JIT will get all the offsets right when it does code generation on the node. I would strongly recommend the shared library approach over this one, because JIT compile time is dominated by code generation, not optimization. If you distribute the .bcs, then

Hello all. I am trying to use WINE to make a windoze-only development environment (very rudimentar, command line cross-compiler and stuff) under Linux, because GNU make is far superior from the M$'s 'nmake'. Anyway, I have some trouble with expirating licenses and stuff, and the solution is to revert the system date back to some valid thing and then compile. Since I am now running

On Tue, 18 Apr 2006, Tom Tromey wrote: >>>>>> "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,

Well I've dabbled with Wine on and off for about a year and quite frankly, I've never gotten Wine to work... in fact I've never gotten Wine to do anything--I don't know why I bother, I guess because sometimes my head inflates, and I just need Wine to tell me that yes tehre are some htings in life I can't have. So I went here: