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

[Dan Gohman]

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 intention is to remove the
> "multiple return value" support in favour of returning structs. 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.

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

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

>
>
> Perhaps if using a non-constant literal struct is not so trivial, a
> instruction can be added for that instead. Ie,
> 	%res = buildagg i32 %a, i32 %b
> 	ret %res
>
> This is still a clean way of building a struct (a lot easier to work  
> with than
> nested insertvalues IMHO) but also leaves the ret instruction simple.

This looks nice, and I wouldn't rule out doing it in the future, but it
gets a little awkward in the case of nested aggregates. For the moment,
I'd like to stick with just one way to build aggregates; insertvalue is
sufficient to do everything needed, even if it isn't the prettiest.

> Anyway, if using a literal struct as an operand would work, then the  
> multiple
> return value ret instruction can probably be removed alltogether.
>
> I've attached a patch with some changes I made to get things working  
> a bit,
> but it's not really a decent patch yet. The changes to Andersens'  
> pass are
> plain wrong, things can break horribly when you fiddle with structs  
> containing
> pointers this way. The others prevent things from asserting and I  
> think they
> are consistent with the current state of the code, but will need  
> change
> depending on what happens to the return instruction.

Thanks for this patch and the several others! As I mentioned before,
insertelement and extractelement are about to be significantly changed,
for constant indices. Once that's in, I'll be happy to work with you to
revise these patches accordingly and integrate them.

Dan