similar to: [LLVMdev] [Help] calling a native C function from inside LLVM IR

Is there a tool to spit LLVM's IR out in a more machine-friendly syntax like XML? -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e

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

As I understand it, first-class structs will allow structs to be passed as function arguments and returned as results (i.e. multiple return values) instead of passing pointers to structs. However, the GEP instruction only handles pointer types. So I do not understand how you will be able to extract the fields of a struct when it is received as a value type. Will the GEP instruction be altered

On Wed, Feb 4, 2009 at 19:19, Jon Harrop <jon at ffconsultancy.com> wrote: > > Is there a tool to spit LLVM's IR out in a more machine-friendly syntax like > XML? > It seems like the correct, if unhelpful, answer to that is bitcode, which is far more machine-friendly (by my definition) than XML. What's your eventual goal?

Does anyone have any LLVM IR examples implementing things using the instructions for SSE, like complex arithmetic or 3D vector-matrix stuff? I'd like to have HLVM use them "under the hood" for some things but I cannot see all of the operations that I was expecting (e.g. dot product) and am not sure what works when (e.g. "Not all targets support all types however."). --

On Wednesday 24 February 2010 03:58:03 Jianzhou Zhao wrote: > I think LLVM OCaml bindings do not support JIT too much. Can you elaborate on this? Several major projects are using OCaml's LLVM bindings to execute non-trivial code via JIT. -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e

On Feb 5, 2010, at 7:19 PM, Jon Harrop wrote: > On Friday 05 February 2010 23:35:15 Evan Cheng wrote: >> Does anyone actually using it? > > Yes, many LLVM-based projects rely upon TCO to work correctly. Ok, that's all I need to know. > >> I'd prefer to just remove it to clean up the implementation if no one has >> any objections. > > Are you

FYI, http://www.informit.com/articles/article.aspx?p=1215438 -Rajika -- http://wso2.org/ http://llvm.org/ http://www.osdev.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090405/79ddb769/attachment.html>

My compiler is generating a bunch of code including the following line: %57 = call fastcc i32 @aux(%1* %0, %1 %1, %1 %46, i32 0, %4 %2) ; <i32> [#uses=1] ret i32 %57 The program works fine as long as this isn't a tail call. If I compile via a .ll and insert "tail" by hand, the program segfaults. However, if I make it a tail call and return an undef i8* or void instead

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

> How do you handle tail calls and value types? I haven't worried too much about optimisation yet, so it doesn't do anything special for tail calls (although neither does the java compiler). LLVM types are translated to their equivalent java primitive type (or currently it raises an assertion if there is no equivalent type). -- David Roberts http://da.vidr.cc/ On Sat, Nov 28, 2009

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

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

This is not a quite fair comparison. Other virtual machines must be doing garbage collection, while LLVM, as it is using C code, it is taking advantage of memory allocation by hand. On Fri, Jan 30, 2009 at 9:56 PM, Jon Harrop <jon at ffconsultancy.com> wrote: > > The release of a new code generator in Mono 2.2 prompted me to benchmark the > performance of various VMs using the

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*,

Has anyone begun collating data structures and algorithms written in LLVM's IL? I am just considering how to implement my first GC and it would help enormously if I could just pull in a concurrent queue written in IL, for example. -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e

On Tue, Feb 24, 2009 at 11:50 AM, Jon Harrop <jon at ffconsultancy.com> wrote: > Thanks for the clarification. That makes a lot more sense! > > LLVM's support for structs is wonderful but I don't think they can be > called "first-class structs" until all such arbitrary restrictions have been > removed, even though the workaround (using sret form) is trivial

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 Monday 07 December 2009 17:55:44 Chris Lattner wrote: > On Dec 7, 2009, at 9:49 AM, Garrison Venn wrote: > > So I gather this means that malloc was removed from the IR because > > there are platforms that don't have non-stack allocation semantics? > > No, it was removed because it wasn't necessary, and the malloc > 'instruction' didn't support 64-bit

I just remembered an anomalous result that I stumbled upon whilst tweaking the command-line options to llvm-gcc. Specifically, the -msse3 flag does a great job improving the performance of floating point intensive code on the SciMark2 benchmark but it also degrades the performance of the int-intensive Monte Carlo part of the test: $ llvm-gcc -Wall -lm -O3 *.c -o scimark2 $ ./scimark2 Using