similar to: [LLVMdev] First-class structs

On Tue, Dec 16, 2008 at 3:18 PM, Jon Harrop <jon at ffconsultancy.com> wrote: > > Apologies for the dumb questions but I'm rustier than I had hoped on this. > > I'm trying to write a mini ML implementation and am considering trying to > optimize tuples into structs to avoid heap allocation when possible. Tuples > are often used to return multiple values in ML so I

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 Feb 1, 2009, at 5:38 AM, Jon Harrop wrote: > > As I understand it, first-class structs will allow structs to be > passed as first-class structs already exist. :) > > 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

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

Unless I am mistaken, LLVM barfs if I try to pass an LLVM function to another function as an argument because functions are second class. However, if I const bitcast the LLVM function to a function pointer when it is defined then I can use that as a first-class function pointer. In particular, I can invoke it directly by emitting a "call" without having to cast it back beforehand.

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

Hi Jon, check out http://llvm.org/docs/LangRef.html#aggregateops Ciao, Duncan.

On 01/07/2010 01:38 PM, David Greene wrote: > The way this works on many targets is that the caller allocates stack > space in its frame for the returned struct and passes a pointer to it > as a first "hidden" argument to the callee. The callee then copies > that data into the space pointed to by the address. <nod> > Long-term, first-class status means that

On Feb 5, 2009, at 3:42 PM, Jon Harrop wrote: > > Unless I am mistaken, LLVM barfs if I try to pass an LLVM function > to another > function as an argument because functions are second class. Huh? can you give an example as llvm IR? You can certainly pass functions by-value as a function pointer. -Chris

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

On Tuesday 15 September 2009 16:32:00 Kenneth Uildriks wrote: > In the latest snapshot from SVN on X86, llc refuses to compile > functions returning structs larger than two i32 members. Does it not handle two double-precision floats for the C99 complex type? Or did you mean "larger" as in more fields rather than larger fields? -- Dr Jon Harrop, Flying Frog Consultancy Ltd.

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

> 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

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 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 Thursday 07 January 2010 21:56:11 Dustin Laurence wrote: > On 01/07/2010 01:38 PM, David Greene wrote: > > The way this works on many targets is that the caller allocates stack > > space in its frame for the returned struct and passes a pointer to it > > as a first "hidden" argument to the callee. The callee then copies > > that data into the space pointed

> 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

I'm having another play with LLVM using the OCaml bindings for a forthcoming OCaml Journal article and I have a couple of remarks: Firstly, I noticed that the execute engine is very slow, taking milliseconds to call a JIT compiled function. Is this an inherent overhead or am I calling it incorrectly or is this something that can be optimized in the OCaml bindings? Secondly, I happened to

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