[LLVMdev] suggestion: multiple results from function call.

[Chris Lattner]

On Mon, 2 Jul 2007, Basile STARYNKEVITCH wrote:
> It could be worthwhile to extend the LLVM language 
> http://llvm.org/docs/LangRef.html#i_call so that calls may return more 
> than one result (for example, Common lisp functions can return more than 
> one result). The intent could be to extend the ABI calling conventions 
> to permit a function to return a few results (all in registers), instead 
> of only one.

Yes, I agree:
http://nondot.org/sabre/LLVMNotes/MultipleReturnValues.txt

> The trade-off is to keep all the results in registers. I would suggest 
> to permit at most three (or perhaps four) results, with the implicit 
> hypothesis that such a calling convention is compatible with all the

The first step is to get the LLVM IR to support it.  Based on that, each 
target can make the 'smart' decision about how to implement particular 
calls.

> Alternatively (this is what Common Lisp usually do) one could permit an 
> arbitrary (but reasonably small) number of results, but this require a 
> fall-back machinery when we are out of registers (spilling results on 
> the call stack is probably mroe tricky than vararg implementation)

Exactly.  For example, the standard trick of passting in a pointer to the 
return area works.

> This would permit some advanced compilers using LLVM to return two or 
> three pointers in registers, perhaps even (for hypothetically very 
> clever compilers) in C or C++ return struct of 3 words in registers, not 
> thru the stack, or some ML implementations returning a couple like (x,y) 
> or triplet like (x,y,z) thru registers (without boxing the couple or 
> triplet)

Yep!

> My intuition is that permitting 2 or 3 results could be really useful 
> (and fairly easy to implement), but more than that (eg 4 or more 
> results) is probably almost useless and complex to implement.

The 'hard' part is really to get the LLVM IR support for this in place.

> Comments are welcome.

I'm certainly interested in having this in LLVM, we just haven't had 
anyone interested in implementing it yet.  Are you? :)

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/