similar to: [LLVMdev] GEPping GEPs and first-class structs

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

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

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

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

Hi, The 'extractvalue' and 'insertvalue' instructions only allow constant indices. If I have an array with variable indices, I need to store it into memory, and then load its sub-elements via GEP. Why could 'extractvalue' not support variable indices like GEP? In general, in which case should source code be translated into 'extractvalue' , and when should

Hi Jon, On 2009-02-19, at 14:00, Jon Harrop wrote: > I'm toying with benchmarks on my HLVM and am unable to get any > performance improvement from optimization passes. I simply copied > the use of PassManager from the Kaleidoscope tutorial: > > Any idea what I might be doing wrong? Has anyone else got this > functionality giving performance boosts from OCaml?

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

On Thursday 19 February 2009 19:00:14 Jon Harrop wrote: > I'm toying with benchmarks on my HLVM and am unable to get any performance > improvement from optimization passes... I just disassembled some of the IR before and after optimization. This example function squares a complex number: let zsqr(r, i) = (r*r - i*i, 2*r*i) My compiler is generating: define fastcc i32 @zsqr({

> 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

Hi Can someone explain to me why we cant use uint64_t for extractvalue and insertvalue indices, while GEP on arrays can have indices of any integer type. Basically if I load an array with UINT_MAX+O (O>=2) elements, I can not extract its last element. Given this restriction I feel we have a bug here (uint64_t is passed as a unsigned). This cant happen because of the if (NumElements > 1024)

On Thursday 19 February 2009 19:32:14 Gordon Henriksen wrote: > Hi Jon, > > On 2009-02-19, at 14:00, Jon Harrop wrote: > > I'm toying with benchmarks on my HLVM and am unable to get any > > performance improvement from optimization passes. I simply copied > > the use of PassManager from the Kaleidoscope tutorial: > > > > Any idea what I might be doing

Hi Dan, > Yes, the intention is that getresult will be removed once first-class > aggregates are a ready replacement. This won't leave LLVM missing the > concept of returning multiple values; a struct can be thought of as > a container for multiple values. I'm not saying we don't have some way of modeling multiple return values, I'm sayin the explicit concept

On 01/20/2015 12:45 PM, Reid Kleckner wrote: > On Tue, Jan 20, 2015 at 9:52 AM, Rodney M. Bates <rodney_bates at lcwb.coop <mailto:rodney_bates at lcwb.coop>> wrote: > > 1) Larger structs are returned differently, via memcpy. Do > these methods of returning struct values show through in > the ultimately generated machine code? It seems hard to

On Jun 2, 2008, at 8:45 AM, Matthijs Kooijman wrote: > Hi Dan, > >> Yes, the intention is that getresult will be removed once first-class >> aggregates are a ready replacement. This won't leave LLVM missing the >> concept of returning multiple values; a struct can be thought of as >> a container for multiple values. > I'm not saying we don't have some

> > On Thursday 19 February 2009 19:00:14 Jon Harrop wrote: >> I'm toying with benchmarks on my HLVM and am unable to get any >> performance >> improvement from optimization passes... > > I just disassembled some of the IR before and after optimization. > This example > function squares a complex number: Something is definitely wrong with the way

Here is the LangRef part of the patch. On Tue, Jan 12, 2010 at 2:11 PM, Chris Lattner <clattner at apple.com> wrote: > > On Jan 11, 2010, at 4:30 PM, Talin wrote: > > I'm working on a new version of the patch. >> >> Another thing I wanted to ask about - do you prefer to have one giant >> patch that has everything, or a series of incremental patches? I can

On Jan 12, 2010, at 5:01 PM, Talin wrote: > Here is the LangRef part of the patch. > +<p>The union type is used to represent a set of possible data types which can > + exist at a given location in memory (also known as an "untagged" > + union). [...] This wording is somewhat misleading; memory in LLVM has no types. How about: "A union type describes an

Hi Dan, > The requirement to update all callers' call instructions when a callee > gets a new return value is also present in the current MRV-mechanism > with getresult. It's not been a problem we've worried about so far. I didn't mean you can get away without updating your calllers, I'm just saying it could be a bit easier. > Can you give some background about

I'm writing a front end for an existing interpreted language with slightly odd semantics for primitive values. Similar to the values in a database table, any value could be null, even for non-pointer types. For example a boolean variable could be true, false, or null. To model this behaviour, I'm passing an {i1, [type]} around for every numeric type. And using insertvalue / extractvalue

On May 30, 2008, at 9:11 AM, Matthijs Kooijman wrote: > Hi all, > > I've been implementing some stuff that uses the new structs-as- > firstclass > values code. Apart from some implementation problems, I'm spotting a > few > structural problems that seem non-trivial to fix. Hi, thanks for your interest! > Furthermore, as far as I've understood, the