From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25035 invoked by alias); 7 Nov 2014 08:50:06 -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 25013 invoked by uid 89); 7 Nov 2014 08:50:05 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-pd0-f170.google.com Received: from mail-pd0-f170.google.com (HELO mail-pd0-f170.google.com) (209.85.192.170) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 07 Nov 2014 08:50:04 +0000 Received: by mail-pd0-f170.google.com with SMTP id z10so2928912pdj.15 for ; Fri, 07 Nov 2014 00:50:02 -0800 (PST) X-Received: by 10.68.143.226 with SMTP id sh2mr10656141pbb.62.1415350202482; Fri, 07 Nov 2014 00:50:02 -0800 (PST) Received: from [192.168.1.9] (c-71-231-231-32.hsd1.wa.comcast.net. [71.231.231.32]) by mx.google.com with ESMTPSA id ez4sm8098247pab.36.2014.11.07.00.50.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 07 Nov 2014 00:50:01 -0800 (PST) From: Jay X-Google-Original-From: Jay 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> <545C770A.9040100@redhat.com> Mime-Version: 1.0 (1.0) In-Reply-To: <545C770A.9040100@redhat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <3BDA9478-588F-47E2-9548-8C2613DAEABA@gmail.com> Cc: Ian Taylor , "Lynn A. Boger" , gcc-patches , "" , "gofrontend-dev@googlegroups.com" , "" Subject: Re: [gofrontend-dev] Re: [PATCH 00/13] Go closures, libffi, and the static chain Date: Fri, 07 Nov 2014 08:50:00 -0000 To: Richard Henderson X-IsSubscribed: yes X-SW-Source: 2014/txt/msg00188.txt.bz2 I worked on what I suspect is similar stuff. I ran into the problem..pardon me if my terminology is wrong..PLT thunks fo= r nested functions trashed registers that were in use. My solution was to m= ark them "hidden" or whatever is the term for not replaceable...also not ex= ported but I recall not replaceable is more important. - Jay On Nov 6, 2014, at 11:38 PM, Richard Henderson wrote: > On 11/06/2014 06:45 PM, Ian Taylor wrote: >> On Thu, Nov 6, 2014 at 5:04 AM, Richard Henderson wrote: >>>=20 >>> 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 indire= ct call >>> that libffi produces. And the indirect calls that Go produces. >>>=20 >>> I'm pretty sure that there are no dynamically linked Go calls that requ= ire the >>> static chain. They're used for closures, which are either fully indire= ct from >>> a different translation unit, or locally bound closures through which t= he >>> optimizer has seen the construction, and optimized to a direct call. >>>=20 >>> Ian, have I missed a case where a closure could wind up with a direct c= all to a >>> lazy bound function? >>=20 >> 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. >=20 > Sorry, I wasn't clear. I know nested functions must be local. >=20 > I'm asking about Go closures, supposing we go ahead with the change to > make them use the static chain register. >=20 > I'm merely pretty sure that calling a closure is either fully indirect > or local direct. >=20 > 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. >=20 > 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. >=20 >=20 > r~