similar to: [LLVMdev] SSE examples

----- Original Message ----- From: "Jon Harrop" <jon at ffconsultancy.com> To: <llvmdev at cs.uiuc.edu> Sent: Sunday, June 21, 2009 2:51 PM Subject: [LLVMdev] SSE examples > > Does anyone have any LLVM IR examples implementing things using the > instructions for SSE, like complex arithmetic or 3D vector-matrix stuff? > I don't have any examples... >

On Monday 22 June 2009 16:37:41 BGB wrote: > as for what targets support which operations, in the case of SSE, go check > the Intel and AMD64 docs. I was assuming that LLVM's implementations were incomplete. Are they now complete? So anything that a CPU can do and LLVM has bindings for is implemented? -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e

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 would have come from HLVM. -- Dr Jon Harrop, Flying Frog Consultancy

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

Following on from the success of our previous OCaml Journal articles covering LLVM, we have begun a series dedicated to the design and implementation of high-level languages using LLVM. In particular, these new articles are more pragmatic in nature and go beyond describing working compilers to also discuss testing, debugging and the performance of LLVM-based compilers. The first article in

On Thursday 18 June 2009 12:28:57 Cory Nelson wrote: > I'm also curious what language uses this and why it is useful :) HLVM is intended to be a general-purpose VM rather than a particular language. > Also, things like this would make lock-free algorithms difficult or > impossible. True. Perhaps that is a good argument for providing both kinds. However, nulls are certainly more

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

On Tue, Feb 16, 2010 at 2:47 AM, Jon Harrop <jon at ffconsultancy.com> wrote: > 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

>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

I have written a variety tests of tail calls for my HLVM and all passed with flying colors until I wrote this test (which is actually for algebraic datatypes) and discovered that it segfaults after ~100k iterations through what I think should be a tail call. Here's the IR: define fastcc { { i8*, i8* }*, i8* } @init({ { i8*, i8* }*, i8* }, i32) { entry: %2 = alloca { i32, { { i8*,

I'm toying with benchmarks on my HLVM and am unable to get any performance improvement from optimization passes. Moreover, some of my programs generate a lot of redundant code (e.g. alloca a struct, store a struct into it and read only one field without using the rest of the struct) and this does not appear to be optimized away. I simply copied the use of PassManager from the Kaleidoscope

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 cannot reproduce the problem. The stack trace they have given me is:

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

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é

On 04/01/2010, at 3:01 PM, Jon Harrop wrote: > On Monday 04 January 2010 01:12:55 Simon Harris wrote: >> I'm investigating "improving" the TCO facilities in LLVM to provide for >> "hard" tail calls. Specifically, this would involve extending the existing >> implementation to discard the stack frame for the caller before executing >> the callee. I

I'm just trying to test HLVM with the latest SVN of LLVM and discovered that llvm::PerformTailCallOpt has disappeared from the code but it is still referred to from LangRef.html. Where did it go? -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e

On Saturday 04 April 2009 09:20:21 Gabriele Farina wrote: > - generate IR from my complier; > - build a VM that converts at runtime my bytecode to IR and executes it; > > I largely prefer the second option because it would be great if I can > continue to use to old programs without having to recompile them. > > Which approach do you suggest ? are there any alternatives ?

The release of a new code generator in Mono 2.2 prompted me to benchmark the performance of various VMs using the SciMark2 benchmark on an 8x 2.1GHz 64-bit Opteron and I have published the results here: http://flyingfrogblog.blogspot.com/2009/01/mono-22.html The LLVM results were generated using llvm-gcc 4.2.1 on the C version of SciMark2 with the following command-line options: llvm-gcc

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

Hi guys, first of all let me say "hello" to everyone. Its the firt message for me in this list and I'm pretty happy that I'll be able to finally start working with LLVM. I've a question for you all if you can help me: a few years ago I've implemented a simple VM for a language we're using in my company. The VM JIT compiles a simple bytecode and executes it.