[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: wip-rtl return location

From: Mark H Weaver
Subject: Re: wip-rtl return location
Date: Thu, 02 Aug 2012 22:29:03 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0

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
     truncate-and-jump RA
     call f

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?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]