search for: hlvm

Jon Harrop wrote: > The simplest way is surely to reuse HLVM because it provides everything you > need and is even written in the right language! ;-) Is there a web page with HLVM docs? There's a README.txt in the subversion repository: https://llvm.org/svn/llvm-project/hlvm/trunk/README.txt which says: HLVM comes with documentation in...

All, Chris Lattner and I had a recent discussion about merging the HLVM (http://hlvm.org/) and LLVM (http://llvm.org/) projects. We agreed in principle and the merging of the two projects will now commence. This merger makes sense for both projects. LLVM needs to expand into the realm of front end tool kits. HLVM provides LLVM with some initial front-end capabilitie...

What happened to the HLVM project? I understand it was intended to be a high-level VM specifically for dynamic languages and this post indicates that it was integrated into the LLVM project last year: http://www.nabble.com/NEWS:-HLVM-merges-with-LLVM-td9627113.html But I cannot find any code in LLVM that looks like it...

Someone is trying to work on HLVM with me but they're hitting a problem that we have not been able to resolve. Specifically, GCC seems to be performing some kind of sanity check for "stack smashing" and is calling abort because it is unhappy with something that the code is doing. However, I am not sure what and ca...

Hi, I am senior student at Tashkent University of Information Technologies and I am highly interested in programming language design. I want to develop Python front-end for HLVM as a part of LLVM participation in Google Summer of Code project. I am in long love with Python programming language for its simplicity and effectiveness. Last year I noticed ShedSkin Python to C++ translator among SoC projects and idea of Python high-performance compiler fascinated me. Later I le...

I took the first two lines of the sample program in the tutorial: hendrik at lovesong:~/dv/lang/hlvm$ cat broken.cpp #include "llvm/DerivedTypes.h" #include "llvm/Module.h" hendrik at lovesong:~/dv/lang/hlvm$ and tried to compile them using the llvm-dev in Debian testing: hendrik at lovesong:~/dv/lang/hlvm$ g++ -o broken.o -c broken.cpp In file included from /usr/include/l...

The (new) HLVM project is continuing to improve and I have graphed and analysed some performance-related data. Beating OCaml on numerical performance using LLVM turned out to be quite easy on x86: http://flyingfrogblog.blogspot.com/2009/03/performance-ocaml-vs-hlvm-beta-04.html This was achieved using a singl...

...gen. If I don't give LLVM the same information >> the x86 codegen has, it's an unfair comparison. > >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: > >http://flyingfrogblog.blogspot.com/2009/03/performance-ocaml-vs-hlvm-beta-04.html For numerical tasks and Array tasks but your graphs show for data manipulation for Lists LLVM is slower. I...

...eed to use the script 'llvm-config' to pass correct arguments to g ++: g++ -o broken.o `llvm-config --cxxflags` broken.cpp On Jun 2, 2008, at 9:43 AM, Hendrik Boom wrote: > I took the first two lines of the sample program in the tutorial: > > > hendrik at lovesong:~/dv/lang/hlvm$ cat broken.cpp > #include "llvm/DerivedTypes.h" > #include "llvm/Module.h" > hendrik at lovesong:~/dv/lang/hlvm$ > > > and tried to compile them using the llvm-dev in Debian testing: > > > hendrik at lovesong:~/dv/lang/hlvm$ g++ -o broken.o -c broken....

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: > > > >http://flyingfrogblog.blogspot.com/2009/03/performance-ocaml-vs-hlvm-beta- > >04.html > > For numerical tasks and Array tasks but your graphs show for data > man...

HLVM is a garbage collected virtual machine built upon LLVM: http://forge.ocamlcore.org/projects/hlvm/ The development of HLVM was described in a series of three OCaml Journal articles that turned out to be among our most popular. Consequently, we have decided to run another series of related arti...

I have committed the changes to HLVM that bring it up to date with respect to the new LLVM 2.6 release: http://hlvm.forge.ocamlcore.org/ This required handling of llcontexts and the injection of a call to the new Llvm_executionengine.initialize_native_target function (that is undocumented) *before* the JIT EE is created, otherw...

>From a cursory glance, it looks like something is messing with the stack canarys. Probably a stack buffer overflow. On Tue, Mar 10, 2009 at 11:41 PM, Jon Harrop <jon at ffconsultancy.com> wrote: > > Someone is trying to work on HLVM with me but they're hitting a problem that > we have not been able to resolve. Specifically, GCC seems to be performing > some kind of sanity check for "stack smashing" and is calling abort because > it is unhappy with something that the code is doing. However, I am not sure...

...till way too difficult. > > > > This is completely untrue. > > I'm afraid I'm going to have to disagree... I failed to get my point across. You're still talking about the difficulty of using LLVM's GC support. I was talking about circumventing it. The shadow stack HLVM uses does not work as you describe and it makes no use of LLVM's GC support, e.g. the llvm.gcroot() intrinsic. This is precisely why it is so much easier to write a working accurate garbage collector as I described. It doesn't have to be hard. You made a rod for your own back by choosing to...

On Sun, Jan 4, 2009 at 2:36 PM, Jon Harrop <jon at ffconsultancy.com> wrote: (...) > But I cannot find any code in LLVM that looks like it would have come from > HLVM. Don't know about the status of the project, but the code seems to be here: http://llvm.org/viewvc/llvm-project/ (in directory "hlvm") Regards, Kevin André

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

I have been working on a high-level virtual machine built upon LLVM since Christmas 2008 and just released the first working version: http://forge.ocamlcore.org/projects/hlvm/ This alpha release of HLVM provides: . Unit, bool, int and float primitive types. . Tuples (as first-class structs). . Homogeneous array type. . Boxed value type. . Function pointers. . Generic printing. . Full tail calls. . Precise garbage collection. . Foreign function interface to C. . JIT co...

The HLVM project is a high-level VM optimized for scientific computing: http://www.ffconsultancy.com/ocaml/hlvm/ I implemented the first-working version of a garbage collector capable of collecting from threads that run in parallel in November. Initial performance was awful due to the overhead of acce...

...> > This is completely untrue. > > > > I'm afraid I'm going to have to disagree... > > I failed to get my point across. You're still talking about the difficulty > of using LLVM's GC support. I was talking about circumventing it. The > shadow > stack HLVM uses does not work as you describe and it makes no use of LLVM's > GC support, e.g. the llvm.gcroot() intrinsic. This is precisely why it is > so > much easier to write a working accurate garbage collector as I described. > It > doesn't have to be hard. You made a rod for you...

...ote: > 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 of the bindings? Fine. > > My only gripe with LLVM's OCaml bindings is the way an error caught on the > LLVM side causes my pr...