similar to: [LLVMdev] LLVM 2.6 and Aggregate Return Values: 64 bit

Hi John, > How well does LLVM 2.6 support aggregate return values for 64 bit > targets? I'm currently working on 64 bit Mac OS X and 64 bit Linux. > Are there any known problems or limitations? on x86-64 it depends on what you are returning, but for example you should be able to return a 128 bit integer fine, but anything more will cause the code generator blow up. This

On Wednesday 20 January 2010 10:07:13 Duncan Sands wrote: > Hi John, > > > How well does LLVM 2.6 support aggregate return values for 64 bit > > targets? I'm currently working on 64 bit Mac OS X and 64 bit Linux. > > Are there any known problems or limitations? > > on x86-64 it depends on what you are returning, but for example you > should be able to return a

Duncan Sands wrote: > Hi John, > > >> How well does LLVM 2.6 support aggregate return values for 64 bit >> targets? I'm currently working on 64 bit Mac OS X and 64 bit Linux. >> Are there any known problems or limitations? >> > > on x86-64 it depends on what you are returning, but for example you > should be able to return a 128 bit integer

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

> So it will stack overflow on tail calls At the moment, yes. But then again, so does java. Also, it looks like they're working on support for tail calls in the Da Vinci Machine[1]. > and break with run-time errors When I said it raises an assertion, I meant at compile-time. > on structs? No, structs are supported. The only unsupported types at the moment (as far as I am aware) are

In the latest snapshot from SVN on X86, llc refuses to compile functions returning structs larger than two i32 members. According to the docs, such limitations can be expected to exist on other platforms. This leads to a number of questions and observations: 1. Is there a good way to retrieve the current target limitations on struct return sizes? 2. The sretpromotion pass does not take struct

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 Sunday 29 November 2009 02:06:04 you wrote: > > So it will stack overflow on tail calls > > At the moment, yes. But then again, so does java. Sure but a lot of people like me are using LLVM precisely because it offers these wonderful features. As long as your JVM backend does not handle these features correctly its utility is greatly diminished. > Also, it looks like

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 Thu, Jan 7, 2010 at 3:38 PM, David Greene <dag at cray.com> wrote: > On Thursday 07 January 2010 15:28, Dustin Laurence wrote: >> I think I'm missing something basic about the semantics of returning an >> aggregate type (in my case, a structure) from a function.  Returning a >> structure containing only compile-time constants is simple enough.  But >> I

On Friday 27 February 2009 18:42:13 Gordon Henriksen wrote: > I agree this could be better. I think it would be prudent of you, > being aware of this problem, to structure your compiler so as to limit > the number of pieces of code which would be effected when you switch > to a copying collector. I think that would make my VM a lot more complicated for no clear practical gain. >

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

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

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>

On 2009-02-27, at 19:58, Jon Harrop wrote: > On Friday 27 February 2009 18:42:13 Gordon Henriksen wrote: >> I agree this could be better. I think it would be prudent of you, >> being aware of this problem, to structure your compiler so as to >> limit >> the number of pieces of code which would be effected when you switch >> to a copying collector. > > I

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

On Tuesday 04 December 2007 16:38, Duncan Sands wrote: > Ah, memory allocation! I think you want to declare a very long array type > and then alloc one of them (rather than trying to alloc a large number of > array components). I see. I was indeed making a mistake. This begs the question of what exactly I was doing though. What exactly does "alloc a large number of array