From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12082 invoked by alias); 19 Dec 2014 16:37:41 -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 12071 invoked by uid 89); 19 Dec 2014 16:37:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham 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, 19 Dec 2014 16:37:38 +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 sBJGbWkr015120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 19 Dec 2014 11:37:32 -0500 Received: from pike.twiddle.home (vpn-48-156.rdu2.redhat.com [10.10.48.156]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sBJGbULP005278; Fri, 19 Dec 2014 11:37:31 -0500 Message-ID: <54945449.5010403@redhat.com> Date: Fri, 19 Dec 2014 16:37:00 -0000 From: Richard Henderson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Ulrich Weigand CC: Richard Henderson , libffi-discuss@sourceware.org, Ulrich.Weigand@de.ibm.com, vogt@linux.vnet.ibm.com, krebbel@linux.vnet.ibm.com Subject: Re: [PATCH 0/4] s390 improvements References: <201412191614.sBJGEwd3013748@d03av02.boulder.ibm.com> In-Reply-To: <201412191614.sBJGEwd3013748@d03av02.boulder.ibm.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014/txt/msg00276.txt.bz2 On 12/19/2014 10:14 AM, Ulrich Weigand wrote: > In the end, it's probably OK for low-level code like libffi to make certain > assumptions on the behavior of the toolchain. I'm not quite sure whether > this actually gets us any significant benefit in this case. Does it really > matter whether ffi_prep_args is called from ffi_call_int vs. ffi_call_SYSV? I think it's the indirect call back to ffi_prep_args that I find ugliest, and for most targets, totally unnecessary. >> It's true that the load of %r15 is now a nop. It hadn't been at one point in >> my development; ffi_prep_args had had more than 5 parameters, and so there was >> extra stack allocated. I suppose if ffi_prep_args were inlined, one could be >> certain of this (since there will be no function calls) and document it as such. > > If we do use such tricks, this version may actually be preferable. I'll post that version shortly. If you still don't like it, then I'll try another tack whereby we simply avoid the indirect call. r~