similar to: [LLVMdev] Plans considering first class structs and multiple return values

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

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 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 Jun 9, 2008, at 4:14 AM, Duncan Sands wrote: > Hi, > >> Will sretpromotion still be needed? If the frontends would generate >> functions >> returning a struct directly instead of using an sret argument, sret >> could >> perhaps be removed alltogether? Though I guess there is an ABI >> difference >> between using sret and returning a

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

Hi, I'm really interested in this effort. What is its status? Is any of it in svn yet? (I only see the insert/extract value instructions so far... nothing w.r.t. creating a first-class struct/array). Can I do anything to help? Marc On Mon, Jun 9, 2008 at 9:15 AM, Devang Patel <dpatel at apple.com> wrote: > > On Jun 9, 2008, at 4:14 AM, Duncan Sands wrote: > >> Hi,

On Jun 2, 2008, at 1:03 PM, Matthijs Kooijman wrote: >> Can you give some background about what kinds of things you're >> thinking >> about for this? > For example, when I have a function returning {i32, i32} and I want > to add > another i32 to that. If this was a function that simply returns two > i32 > values, any caller will only use extractvalue on

Hello, The basic infrastructure is in place. You can create first-class structs/arrays using sequences of insertvalue. For example, this: %t0 = insertvalue { i32, i32 } undef, i32 %a, 0 %t1 = insertvalue { i32, i32 } %t0, i32 %b, 1 creates the value with %a and %b as member values. Other ways to produce aggregate values are loads, function arguments, function return values, and literal

Hi Chris, On Sat, Jun 07, 2008 at 02:59:03PM -0700, Chris Lattner wrote: > On Jun 2, 2008, at 1:03 PM, Matthijs Kooijman wrote: > >> Can you give some background about what kinds of things you're > >> thinking > >> about for this? > > For example, when I have a function returning {i32, i32} and I want > > to add > > another i32 to that. If

> For example, this: > > %t0 = insertvalue { i32, i32 } undef, i32 %a, 0 > %t1 = insertvalue { i32, i32 } %t0, i32 %b, 1 > > creates the value with %a and %b as member values. Is there anyway to do it using the C++ API? It seems I need an instance of the aggregate type to pass into InsertValueInst::Create(). What is the API equivalent of "undef"? Marc On Wed,

Thanks for the replies, Daniel and Matthijs. I added some code to generate the copy constraint, which I think (in the present form) is wrong (or at best not field sensitive): +void Andersens::visitGetResultInst(GetResultInst &GR) { + if (isa<PointerType>(GR.getType())) + { + // P1 = getresult P2 --> <Copy/P1/P2> +

Hi, > Will sretpromotion still be needed? If the frontends would generate functions > returning a struct directly instead of using an sret argument, sret could > perhaps be removed alltogether? Though I guess there is an ABI difference > between using sret and returning a structure directly? right, there's an ABI difference. Also you can't return variable sized structs using

On Tuesday 22 July 2008 01:23, Chris Lattner wrote: > David, I'm not sure I follow. It is, of course, very important for us > that llvm-gcc generate ABI compliant code on x86-64. I'm just saying > that if struct-return does not provide the ABI required for a specific > source construct that another lowering would be needed. Ah, ok. I misunderstood your statement. > In

On Jul 23, 2008, at 9:05 AM, David Greene wrote: >> In the case of X86-64, llvm-gcc does use aggregate return (for the >> interesting cases which return things in registers) and it does do >> the > > I don't follow. By "aggregate return" do you mean "structs as first > class > values?" That is, llvm-gcc generates a return of a struct by

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

----- Original Message ----- > From: "deadal nix" <deadalnix at gmail.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Mehdi Amini" <mehdi.amini at apple.com>, "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Friday, August 21, 2015 1:24:04 AM > Subject: Re: [llvm-dev] [RFC] Aggreate load/store, proposed plan >

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

----- Original Message ----- > From: "deadal nix" <deadalnix at gmail.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Mehdi Amini" <mehdi.amini at apple.com>, "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Thursday, August 20, 2015 4:09:17 PM > Subject: Re: [llvm-dev] [RFC] Aggreate load/store, proposed plan >

What's the current status on support for first-class structs? The last I heard was: - Structs which are smaller or equal to two pointers can be passed / returned / loaded / stored by value. - There are plans to expand this in the future to support arbitrary-sized structs as first class values. (Probably via some transformation pass the converts the return value into a hidden

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