llvm dev - Jun 2008 - [LLVMdev] Plans considering first class structs and multiple return values

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 this was a function that simply returns two  
> > i32
> > values, any caller will only use extractvalue on the result to get the
> > seperate values (since the struct as a whole has no meaning). In  
> > this case, I
> > can make the function return {i32, i32, i32}, add an extra  
> > extractvalue in
> > each caller and be done.
> 
> This can't really work in either case.  Once created, there is no way  
> to change the type of a Value*.  Changing the result of a call from  
> {i32, i32} to {i32, i32, i32} is just as impossible as changing it  
> from {i32,i32} to i32.  You have to create a new callinst in either  
> case.
By "Changing the return type", I meant "Create a new function
with a changed
return type and updating all calls". The argument still holds, that this is
easier to do in some cases than others.

> > { {i32, i32}, i32}, which means we get something like:
> >
> > 	%tmp = @foo () ; { {i32, i32}, i32}
> > 	%complex  = extractvalue { {i32, i32}, i32} %tmp, 0
> > 	@bar ( {i32, i32 } %complex)
> 
> Why would you ever want to pass multiple values as an aggregate to a  
> call?  The only thing I can think of is for ABI reasons.  If you can  
> do an ABI changing transformation (such as you propose) the first  
> thing I'd do is  expand the aggregate to pass as a series of scalars.
> Having argpromotion do this would be very natural.
I was just using @bar to show that the complex struct is used as-is somewhere,
so it can't be broken up completely. In this particular case, it could be
that
@foo() is internal (and thus can be changed) but @bar is external and has to
be kept unchanged.

Anyway, it was just an example.

In practice, just taking whatever the function is returning now, and put that
into a struct together with whatever you want to add and then letting other
passes make something pretty out of the resulting extractvalue/insertvalue
forest will work just fine.
> After MRVs are working really well, I'd like to consider removing the  
> void type:
> http://nondot.org/sabre/LLVMNotes/EliminatingVoid.txt
> 
> This would make it so that calls always return a value, and 'ret'  
> always takes a value.  This would be a nice simplification to the IR I  
> think.
Doing this will make functions returning a single value stand out even more,
since a function returning 0 or more than 1 values will always return a
struct, while a function returning 1 value will just return that value.
Don't
think this is really a problem, though.
> If you're using IRBuilder, why not just add a new CreateBuildMRV  
> method that inserts the sequence of insertvalue's for you?
Hmm, that would actually make sense I guess. I'm not currently using
IRBuilder, but I might move some code into there.
> stretpromotion was really just for testing.  I expect that when MRVs  
> work predictably 100% of the time (even if not something the ABI  
> supports, for example) that the functionality will be pulled into the  
> argpromotion pass.
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?

Gr.

Matthijs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20080609/845b4de8/attachment.sig>

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 MRV support (I don't know if gcc really supports this, but some pieces
of
code inside gcc mention functions returning variable sized objects).

Ciao,

Duncan.

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 structure directly?
>
> right, there's an ABI difference.  Also you can't return variable  
> sized structs
> using MRV support (I don't know if gcc really supports this, but  
> some pieces of
> code inside gcc mention functions returning variable sized objects).
Plus it is not a good idea to pass very large structs using MRV.
-
Devang

* Duncan Sands:
> right, there's an ABI difference.  Also you can't return variable
sized structs
> using MRV support (I don't know if gcc really supports this, but some
pieces of
> code inside gcc mention functions returning variable sized objects).
At one point, the MIPS back end supported returning variably-sized
structs with an elevated stack pointer (the goal was to remove the need
for Ada's secondary stack), but that has been removed since then.