similar to: [LLVMdev] Efficient implementation of closures?

On Sunday 28 December 2008 05:53:55 Talin wrote: > The second solution is that when calling via a pointer, we always call > with the closure protocol, i.e. we include the hidden parameter. > However, when taking the address of a non-closure function, we actually > point to a stub function which strips off the hidden parameter before > calling the real function. This solution is

On Sun, Dec 28, 2008 at 13:42, Jon Harrop <jon at ffconsultancy.com> wrote: > > Previous generation languages like OCaml compile this into a completely > generic representation where polymorphism is handled at run-time. > Consequently, even though the polymorphism is buried in the fold function > (not visible at all in our "sum" function) it still incurs massive >

Hello, Everyone LLVM recently was approved to take part in Google Summer of Code 2008. We welcome everyone to apply for this program. The list of ideas for (possible) projects is located at http://llvm.org/OpenProjects.html. Surely you can suggest any other project, if you feel, that it definitely can be useful. Our common requirement for student is to submit proposal to LLVM Developers

> Why do you say that people who compile, e.g., functional languages > would benefit from type variables in LLVM? > I like the level the LLVM is at, and would prefer to deal with > instantiating parametric polymorphism at a higher level. I'm surprised you're happy with a non-polymorphic llvm. Does Cayenne target llvm? Dependent types take polymorphism to new heights -- but

On Tuesday 18 March 2008 20:17:52 Anton Korobeynikov wrote: > Hello, Everyone > > LLVM recently was approved to take part in Google Summer of Code 2008. > We welcome everyone to apply for this program. > > The list of ideas for (possible) projects is located at > http://llvm.org/OpenProjects.html. Surely you can suggest any other > project, if you feel, that it definitely

>On Sunday 14 June 2009 14:09:33 Wesley W. Terpstra wrote: >> On Sun, Jun 14, 2009 at 10:50 AM, Florian Weimer<fw at deneb.enyo.de> wrote: >> > Is this really a problem for MLton? I think you only get less precise >> > alias analysis, and that's it. >> >> Correct. However, I want a fair comparison between LLVM performance >> and the native x86

> The same can be said of closures, garbage collection and a dozen other > features that also cannot feasibly be added to LLVM. > > The only logical solution is to build a HLVM on top of LLVM and share that > between these high-level language implementations. This is an excellent point. You have convinced me. :-) BTW, what garbage collector are you using for your HLVM? You

On Sun, Jun 14, 2009 at 10:50 AM, Florian Weimer<fw at deneb.enyo.de> wrote: > Is this really a problem for MLton?  I think you only get less precise > alias analysis, and that's it. Correct. However, I want a fair comparison between LLVM performance and the native x86 codegen. If I don't give LLVM the same information the x86 codegen has, it's an unfair comparison.

Hello All (to Ocaml List & CC LLVM list) As some might probably know, the LLVM compiler http://llvm.org/ has (at least in its latest SVN snapshot) a binding for Ocaml. This means that one could code in Ocaml some stuff (eg a JIT-ing compiler) which uses (and links with) LLVM libraries. http://lists.cs.uiuc.edu/pipermail/llvmdev/2007-November/011481.html

Hi all, I would like to implement GC for a language supporting multiple threads. There will be no shared state between threads as communication will be based on message passing. I do not care much about performance. The priority for me is to get things working. I have read LLVM guide on writing GC: http://llvm.org/docs/GarbageCollection.html. Shadow stack approach looks very promising. The

On Wednesday 12 December 2007 13:39, Gordon Henriksen wrote: > Since that ASTs are by definition language-specific, such should > probably be a separate project because LLVM itself is language-agnostic. Well, I'd like this to factor out commonality from the implementations of all managed languages (everything from C++ to Lisp) so I think it should express a typed language with typical

On Monday 10 December 2007 23:52, Gordon Henriksen wrote: > On 2007-12-10, at 18:28, Jon Harrop wrote: > > Incidentally, should more OCaml stuff beyond the bindings be part of > > LLVM or would it be better to fork them into a separate project > > Can you be more specific than "stuff"? I'm thinking of a library that compiles an AST represented by an OCaml data

On Mon, 25 Oct 2004, Marc Ordinas i Llopis wrote: > Misha Brukman wrote: > >>1. Opcodes and intrinsics > >> > > That's not really correct. The intrinsics such as llvm.frameaddress and > > llvm.returnaddress have no equivalents in LLVM opcodes -- the meaning of > > the intrinsics is specifically machine-dependent, and LLVM (and its > > opcodes) are

On Tuesday 16 June 2009 15:44:04 Aaron Gray wrote: > Jon Harrop wrote: > >Even if this puts LLVM at an unfair disadvantage, I think you will find > >that > >LLVM will thrash MLton's current x86 backend anyway. > > > >I did some benchmarking on HLVM and found that it was often several times > >faster than OCaml when the GC is not the bottleneck: > >

Attached are updated LLVM-OCaml Bindings Tutorial from Chris Wailes. (http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-April/021804.html) We changed them to work with the latest APIs(LLVM2.6 and the latest LLVM from SVN). Does anyone know if there is any realistic project using LLVM-OCaml Bindings? How is the performance? Jianzhou -------------- next part -------------- A non-text attachment was

On Wednesday 22 April 2009 12:15:09 Chris Wailes wrote: > That is perfectly understandable. My problem was that I had never seen the > stream syntax before. While I'm no OCaml master, I have used it for a > while and so it might be that other people coming to the tutorial may have > the same experience. This page may be of help:

On Tuesday 16 February 2010 03:51:00 Jianzhou Zhao wrote: > Does anyone know if there is any realistic project using LLVM-OCaml > Bindings? I've written a VM in OCaml built upon LLVM using LLVM's OCaml bindings: http://www.ffconsultancy.com/ocaml/hlvm/ There are at least two other significant users of LLVM's OCaml bindings, AFAIK. > How is the performance? Performance

I am using LLVM as the last stage of a compiler in order to easily produce a binary in native code. My compiler is implemented in Ocaml and has various layers of languages. In the last layer prior to LLVM, I have a value which has been converted to CPS, closure and hoisting (of functions). I am now trying to write a garbage collector for this language. The shadow stack is not suitable for me,

A while back there was a discussion thread about whether an accurate, concurrent garbage collector could be "generic" in the sense of being able to support multiple different languages efficiently. After having done some work on this, I now believe that this is the case - using C++ policy-based design principles, you can create a set of modules that represent different aspects of

> > I'm happy to apply any patches :) Even better if you wanted to extend > the tutorial to support things like garbage collection. As I go along in my project and explore these features I might be willing to produce code for additional chapters but I don't think I have time to dedicate to it now. What was the problem? I just tested it out on fedora 10 and it worked > after