From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7797 invoked by alias); 7 Nov 2014 07:39:14 -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 7721 invoked by uid 89); 7 Nov 2014 07:39:13 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=unavailable version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 07 Nov 2014 07:39:12 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sA77d3fs012724 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 7 Nov 2014 02:39:03 -0500 Received: from pike.twiddle.home (vpn1-4-243.ams2.redhat.com [10.36.4.243]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sA77cxk6024039; Fri, 7 Nov 2014 02:39:00 -0500 Message-ID: <545C770A.9040100@redhat.com> Date: Fri, 07 Nov 2014 07:39:00 -0000 From: Richard Henderson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Ian Taylor CC: "Lynn A. Boger" , gcc-patches , libffi-discuss@sourceware.org, "gofrontend-dev@googlegroups.com" , ian@airs.com Subject: Re: [gofrontend-dev] Re: [PATCH 00/13] Go closures, libffi, and the static chain References: <1412973773-3942-1-git-send-email-rth@redhat.com> <545A97BA.3030507@linux.vnet.ibm.com> <545B1C44.3000306@redhat.com> <20141106124838.GJ30857@bubble.grove.modra.org> <545B71D1.1090406@redhat.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2014/txt/msg00187.txt.bz2 On 11/06/2014 06:45 PM, Ian Taylor wrote: > On Thu, Nov 6, 2014 at 5:04 AM, Richard Henderson wrote: >> >> That said, this *may* not actually be a problem. It's not the direct (possibly >> lazy bound) call into libffi that needs a static chain, it's the indirect call >> that libffi produces. And the indirect calls that Go produces. >> >> I'm pretty sure that there are no dynamically linked Go calls that require the >> static chain. They're used for closures, which are either fully indirect from >> a different translation unit, or locally bound closures through which the >> optimizer has seen the construction, and optimized to a direct call. >> >> Ian, have I missed a case where a closure could wind up with a direct call to a >> lazy bound function? > > I think you've covered all the cases. The closure value is only > required when calling a nested function. There is no way to refer > directly to a nested function defined in a different shared library. > The only way you can get such a reference is if some function in that > shared library returns it. Sorry, I wasn't clear. I know nested functions must be local. I'm asking about Go closures, supposing we go ahead with the change to make them use the static chain register. I'm merely pretty sure that calling a closure is either fully indirect or local direct. Certainly there are cases in the testsuite where -O3 is able to look through the creation of a closure and have a direct call to the function. Given that closures are custom created for the data at the creation site, it seems unlikely that the optimizer could look through that and come up with a dynamically bound function. r~