Re: wip-rtl return location

[Mark H Weaver <mhw@netris.org>]

Hi Andy, thanks for the update!  Exciting times for Guile :)

On 08/02/2012 10:29 AM, Andy Wingo wrote:
> Instead I'd rather just use Dybvig's suggestion: every call instruction
> is preceded by an MV return address.  For e.g. (values (f)), calling `f'
> would be:
>
>      ...
>      goto CALL
> MVRA:
>      truncate-and-jump RA
> CALL:
>      call f
> RA:
>      return
>
> So the overhead of multiple values in the normal single-value case is
> one jump per call.  When we do native compilation, this cost will be
> negligible.  OTOH for MV returns, we return to a different address than
> the one on the stack, which will cause a branch misprediction (google
> "return stack buffers" for more info).

I wonder if it might be better to avoid this branch misprediction by 
always returning to the same address.  Upon return, a special register 
would contain N-1, where N is the number of return values.  The first 
few return values would also be stored in registers (hopefully at least 
two), and if necessary the remaining values would be stored elsewhere, 
perhaps on the stack or in a list or vector pointed to by another register.

In the common case where a given call site expects a small constant 
number of return values, the compiler could emit a statically-predicted 
conditional branch to verify that N-1 is the expected value (usually 
zero), and then generate code that expects to find the return values in 
the appropriate registers.

On some architectures, it might also make sense for the callee to set 
the processor's "zero?" condition code as if N-1 had been tested, to 
allow for a shorter check in the common single-value case.

Of course, the calling convention can be chosen independently for each 
instruction set architecture / ABI.

What do you think?

     Mark