From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andy Wingo Newsgroups: gmane.lisp.guile.devel Subject: Re: wip-rtl return location Date: Fri, 03 Aug 2012 10:24:30 +0200 Message-ID: <87y5lwtmbl.fsf@pobox.com> References: <87mx2dv02q.fsf@pobox.com> <501B376F.3060505@netris.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1343982291 2140 80.91.229.3 (3 Aug 2012 08:24:51 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 3 Aug 2012 08:24:51 +0000 (UTC) Cc: guile-devel To: Mark H Weaver Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Aug 03 10:24:48 2012 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1SxDBd-0003VG-UI for guile-devel@m.gmane.org; Fri, 03 Aug 2012 10:24:46 +0200 Original-Received: from localhost ([::1]:49915 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SxDBd-0003o2-8C for guile-devel@m.gmane.org; Fri, 03 Aug 2012 04:24:45 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:50074) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SxDBX-0003n9-Cf for guile-devel@gnu.org; Fri, 03 Aug 2012 04:24:43 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SxDBS-0004ma-UW for guile-devel@gnu.org; Fri, 03 Aug 2012 04:24:39 -0400 Original-Received: from a-pb-sasl-quonix.pobox.com ([208.72.237.25]:63541 helo=sasl.smtp.pobox.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SxDBS-0004mT-Q9 for guile-devel@gnu.org; Fri, 03 Aug 2012 04:24:34 -0400 Original-Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id B18259760; Fri, 3 Aug 2012 04:24:33 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=sasl; bh=2a5k1weVjGyncDN1p09O5X6XWGw=; b=FVMYyB Rw7xnW5ufJH1590klaqCgLlxU1MdPfQEPSfF1ZXOg7cIJZDsD0k+hBIy3x4gY9lT PZt8KxbTgoQnu1J2pvM//WGrxBvajP/OlDO4h+xDQcPF378NtQbO7E9dq8Acfq/D 4T3Fhy94Q7FSxgQp3PuMZ0QAmqOjhQVI/o6BU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; q=dns; s=sasl; b=RLfeg0jZu7cFSzik9XNdkvAGvU+EzGwa 9meM7dtjrjfccKI5ctVt3hvYyBfzWDXu5p4O2478L3T/ySNfU5q/iTSO7VtbG/gD 0h7Xjch/wq11xQPf0ysQkzHQVv0mloEhtmMN1AdFMk0vIgrfdnvAt1/dpHN16/MM ATtJHT9SRpM= Original-Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id A2FB2975F; Fri, 3 Aug 2012 04:24:33 -0400 (EDT) Original-Received: from badger (unknown [91.117.99.155]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 099AA975E; Fri, 3 Aug 2012 04:24:32 -0400 (EDT) In-Reply-To: <501B376F.3060505@netris.org> (Mark H. Weaver's message of "Thu, 02 Aug 2012 22:29:03 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux) X-Pobox-Relay-ID: A7459096-DD44-11E1-97F2-11610E5B5709-02397024!a-pb-sasl-quonix.pobox.com X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 208.72.237.25 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:14769 Archived-At: Heya Mark, Thanks for the comments :-) So the current thing is: CALL: call f MVRA: truncate RA: return In interpreted code it's fine that we return to a different address, as they are all indirect jumps anyway. For compiled code, the "call" instruction won't be just one instruction -- in RTL it's a macro-instruction that also handles shuffling the arguments into place, whereas with native compilation you would handle the shuffling then do the call. So for native compilation you could put the MVRA before the call because the call would have fixed width. Anyway, on to your point: On Fri 03 Aug 2012 04:29, Mark H Weaver writes: > 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. It's a good idea for the native-compilation case. I don't think the overhead of the conditional jump in interpreted code would be worth it, though. Dunno. Probably wouldn't matter? > 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. But here's the rub, this introduces a conditional branch into the calling sequence where there was no conditional branch before (for the single-valued case, which is empirically the majority of cases). Apparently the intel Core architecture ignores static branch predictions: http://www.agner.org/optimize/microarchitecture.pdf So it would increase pressure on the branch target buffer. OTOH the dynamic predictions would almost always hit, in either case. > 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? I think it's definitely worth exploring. I would be OK with it, and receiving results in registers would be good. In the context of what we do with the bytecode (as opposed to calling convention optimizations that we will do with native code), WDYT about the bytecode calling convention I outlined above? Cheers, Andy -- http://wingolog.org/