From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2008 invoked by alias); 7 Nov 2014 16:06:57 -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 1987 invoked by uid 89); 7 Nov 2014 16:06:56 -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,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=unavailable version=3.3.2 X-HELO: mail-yh0-f51.google.com Received: from mail-yh0-f51.google.com (HELO mail-yh0-f51.google.com) (209.85.213.51) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 07 Nov 2014 16:06:55 +0000 Received: by mail-yh0-f51.google.com with SMTP id z6so2577173yhz.10 for ; Fri, 07 Nov 2014 08:06:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=GMdy69025mh3u29PqXTWfMdRq84GkYdnvSbZTEcRUuE=; b=mZQ8Nd1Qm1tN2ntnN+8AJpqLKfHkWdQbP+5Lrf8jGJjEDKPdbqWVXYsC330k6jDb4R FRHW94s/w7GHZrb3GVrGcqCnxXnB389uMJjnw7lczQd1IUBFDrq7PeJYgS5jh/rF4WnO 0PZulApnGBy7WkElNnOcxgjT5eSXI94aLoCPTmpYBf33UtgYkA9DsajTGwSudHIOX/le ozJlHZ3PxeFpXpT/u4ihTAG2fAthODC3HMns3qzq0PnHz+FhDhADIS0Qs748I5h5jMq0 LMm2Wxe71qZ+e1jwJ3Yjh2nSG02udx6y8N5qryRkaQCaS2k62aTGjfnCA8iiLGQSPtvd Cicw== X-Gm-Message-State: ALoCoQkvM2MA73rFifeuJRy946phXIayDSOUD+Xy9AYqDTXEKDVDj9vT0aY7oK5V726p32IFpNgx MIME-Version: 1.0 X-Received: by 10.236.70.229 with SMTP id p65mr11773939yhd.86.1415376412995; Fri, 07 Nov 2014 08:06:52 -0800 (PST) Received: by 10.170.136.18 with HTTP; Fri, 7 Nov 2014 08:06:52 -0800 (PST) In-Reply-To: <545C770A.9040100@redhat.com> 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> Date: Fri, 07 Nov 2014 16:06:00 -0000 Message-ID: Subject: Re: [gofrontend-dev] Re: [PATCH 00/13] Go closures, libffi, and the static chain From: Ian Taylor To: Richard Henderson Cc: "Lynn A. Boger" , gcc-patches , libffi-discuss@sourceware.org, "gofrontend-dev@googlegroups.com" , Ian Lance Taylor Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2014/txt/msg00203.txt.bz2 On Thu, 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: >>> >>> 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 think we're saying the same thing. Closures exist only for nested functions and for functions created by reflect.MakeFunc and friends. Storing a top-level function into a variable will give you something that looks like it has a closure, but the closure will always be empty and it will never be used. The indirect call will set the closure value in the static chain register, but the register will not be used by the function being called. > I'm merely pretty sure that calling a closure is either fully indirect > or local direct. Yes. > 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. Yes. Ian