From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20261 invoked by alias); 19 Dec 2014 14:48:50 -0000 Mailing-List: contact libffi-discuss-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libffi-discuss-owner@sourceware.org Received: (qmail 20198 invoked by uid 89); 19 Dec 2014 14:48:49 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,MSGID_FROM_MTA_HEADER,SPF_SOFTFAIL,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: e38.co.us.ibm.com Received: from e38.co.us.ibm.com (HELO e38.co.us.ibm.com) (32.97.110.159) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Fri, 19 Dec 2014 14:48:48 +0000 Received: from /spool/local by e38.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 19 Dec 2014 07:48:46 -0700 Received: from d03dlp02.boulder.ibm.com (9.17.202.178) by e38.co.us.ibm.com (192.168.1.138) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 19 Dec 2014 07:48:44 -0700 Received: from b03cxnp08026.gho.boulder.ibm.com (b03cxnp08026.gho.boulder.ibm.com [9.17.130.18]) by d03dlp02.boulder.ibm.com (Postfix) with ESMTP id 9E56E3E40041 for ; Fri, 19 Dec 2014 07:48:43 -0700 (MST) Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by b03cxnp08026.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id sBJEnLUS43909332 for ; Fri, 19 Dec 2014 07:49:21 -0700 Received: from d03av02.boulder.ibm.com (localhost [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id sBJEmgq3027435 for ; Fri, 19 Dec 2014 07:48:43 -0700 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d03av02.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with SMTP id sBJEmeUw027195; Fri, 19 Dec 2014 07:48:40 -0700 Message-Id: <201412191448.sBJEmeUw027195@d03av02.boulder.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Fri, 19 Dec 2014 15:48:40 +0100 Subject: Re: [PATCH] Go closures for s390[x] To: rth@redhat.com (Richard Henderson) Date: Fri, 19 Dec 2014 14:48:00 -0000 From: "Ulrich Weigand" Cc: libffi-discuss@sourceware.org, Ulrich.Weigand@de.ibm.com (Ulrich Weigand), krebbel@linux.vnet.ibm.com (Andreas Krebbel) In-Reply-To: <549431B0.10806@redhat.com> from "Richard Henderson" at Dec 19, 2014 08:09:52 AM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 14121914-0029-0000-0000-0000068512E1 X-SW-Source: 2014/txt/msg00272.txt.bz2 Richard Henderson wrote: > On 12/19/2014 07:13 AM, Ulrich Weigand wrote: > > Actually, it sort-of is; the code does: > > la %r14,0(%r13,%r9) # Set return address > > br %r7 # ... and call function > > > > i.e. sets the return address register to point to one of the return stubs > > and then jumps to the target function instead of calling it; so from the > > point of view of an unwinder, it looks like the target function was called > > from the instruction immediately preceding the return stub. > > Ah, good point. That's the sort of verbage that should be in the comment then. > > Is that optimization really worth it? Is there no call/return prediction stack > to get confused? I know I replicated it in the code that I wrote, but really > only now do I start to question it. There's no call/return stack as such on current processors; we don't have hard-coded call/return instructions, and the various OSes on the platform use registers in quite different ways as part of their calling conventions. However, I agree that in general it's probably best to avoid tricks like that. -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com