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

[Chris Lattner]

On May 30, 2008, at 10:40 AM, Dan Gohman wrote:
>> Furthermore, as far as I've understood, the intention is to remove  
>> the
>> "multiple return value" support in favour of returning structs.

Yep.

>> I
>> take it this
>> means that at least the getresult instruction will be removed, and
>> possible
>> the multiple operand return as well. This would partly solve some
>> issues, but
>> will completely remove the concept of returning multiple values
>> (unless you
>> adopt the above approach of always returning structs, even for
>> single values).
>
> 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.

Right.

>
>
>> Additionally, the current form of the ret instruction is still
>> useful, for
>> making multiple return values readable. In particular, writing
>> 	ret i32 1, i32 2
>> is a lot more readable than the (functionally identical) three line
>> return
>> statement above. However, to make the first class aggregrates even
>> more
>> usable, it might be better to remove the multi operand return
>> instruction and
>> add support for literal aggregrates. Currently, I think these are  
>> only
>> supported as global constants. It would be useful if the following
>> was valid:
>> 	ret { i32, i32 } { i32 1, i32 2 }
>
> I think this form should be valid once first-class struct support is
> more
> complete. If it's not accepted today it may be a conflict with the
> current
> multiple-return-value syntax, or it may be a bug.

Right.  Returning a ConstantStruct should be legal, and not a real  
problem.

>> Even more, one would also like to be able to build non constant
>> structs in a
>> similar manner. i.e., writing
>> 	ret { i32, i32 } { i32 %a, i32 %b }
>> would be a lot more useful than the current
>> 	ret i32 %a, i32 %b
>> form, since in the first form the ret instruction still has a single
>> operand
>> that is easy to work with.
>
> The current design will have it looking like this:
>
>        %t0 = insertvalue { i32, i32 } undef, i32 %a, 0
>        %t1 = insertvalue { i32, i32 } %t0,   i32 %b, 1
>        ret { i32, i32 } %t1
>
> once first-class structs take over from the current multiple-return-
> value
> support. It's significantly more syntax, but it's a significantly
> simpler
> IR schema.

Agreed.  Thanks to both of you for working on this!

-Chris