similar to: [LLVMdev] struct returns

On Tue, Sep 15, 2009 at 11:55 AM, Dan Gohman <gohman at apple.com> wrote: > > On Sep 15, 2009, at 8:32 AM, Kenneth Uildriks wrote: > >> 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.

On Sep 15, 2009, at 8:32 AM, Kenneth Uildriks wrote: > 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

Kenneth Uildriks wrote: > On Tue, Sep 15, 2009 at 11:55 AM, Dan Gohman <gohman at apple.com> wrote: > >> On Sep 15, 2009, at 8:32 AM, Kenneth Uildriks wrote: >> >> >>> In the latest snapshot from SVN on X86, llc refuses to compile >>> functions returning structs larger than two i32 members. >>> >>> According to the docs,

> I recently made a major reorganization of the calling-convention > lowering code which cleared away one of the major obstacles to > doing this within codegen. > > Dan So what was the obstacle, and how was it cleared? And how do you see the large struct return working in codegen? Anything you care to tell me would be welcome. I will be starting on this today or tomorrow.

On Sep 16, 2009, at 5:58 AM, Kenneth Uildriks wrote: >> I recently made a major reorganization of the calling-convention >> lowering code which cleared away one of the major obstacles to >> doing this within codegen. >> >> Dan > > So what was the obstacle, and how was it cleared? The biggest obstacle is that there used to be two different methods for lowering

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

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

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

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

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

Hi, The attached patch removes sretpromotion from docs/Passes.html The sretpromotion pass got removed in version 3.0 Cheers, Stephan -------------- next part -------------- A non-text attachment was scrubbed... Name: Passes.html.patch Type: text/x-patch Size: 1904 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121122/11cd69f9/attachment.bin>

Good evening, guys! At first, I apologize my report is a little gross, I have so little time to do checking process minutely. * RC1 RC1 can be built on VS8, 9, 10 with Debug|Release. At one point, r127264(in release_29/trunk) is needed to build with Debug on VS10. RC1 can pass clang-test with any configurations. RC1 fails llvm's check on many tests. * RC1 and patches ToT would be ready

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

Now that we can safely return arbitrarily large structs on x86, it seems to me that fastcc, which doesn't have to conform to any preexisting ABI, should use ECX as well as EAX and EDX for returning {i32,i32,i32} rather than use sret-demotion. Any objections?

I wish to assure you that I have not forgotten this task, nor failed to start on it, but I cannot give even a rough estimate on when it will be completed. It occurs to me that all declarations of a function pointer, and all bitcasts to a function pointer, could possibly refer to a function whose signature must be altered by this fix. Is the function signature relevant to the SelectionDAG

Hi Rich, > I was thinking about my problem and thought that there might be a good > interim solution. I would like not to clutter my front end with stuff > that will go away. How about a pass that runs before code generation > that changes functions returning structs to void functions with the > return pointer first parameter? On this topic, you should look at the

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