similar to: [LLVMdev] How to declare and use sprintf

So my Fib program is segfaulting and I'm not sure why. I think it might be because my declaration and use of sprintf is wrong. I notice llvm-gcc produces declarations containing "..." like: declare int %printf(sbyte*, ...) but I'm not sure how to do this so I've used: let sprintf = declare_function "sprintf" (function_type (pointer_type

On Nov 25, 2007, at 18:53, Jon Harrop wrote: > So my Fib program is segfaulting and I'm not sure why. I think it > might be because my declaration and use of sprintf is wrong. > > I notice llvm-gcc produces declarations containing "..." like: > > declare int %printf(sbyte*, ...) > > What is the correct way to do this? The type you want is: let sp =

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

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

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

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

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

> 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

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

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

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 Monday 15 June 2009 01:32, me22 wrote: > My (possibly faultly) understanding is that intel's has good support > for numerics, presumably through auto-vectorization and such, but only Yes, that's true. > works for intel's architectures and is only excellent on intel chips. That used to be the case, but not so anymore. Intel compilers generate just fine code for AMD

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

> If you translate to a big array of memory and index into it, how is it > better than the mips -> java compiler? Yes, it is similar to the mips to java compiler in that regard, but it does have several advantages over it. For example, functions are mapped to individual methods (rather than just a big chunk of translated instructions), allowing Java to call individual functions in the