From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7470 invoked by alias); 29 Oct 2014 20:44:47 -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 7439 invoked by uid 89); 29 Oct 2014 20:44:44 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-qg0-f49.google.com Received: from mail-qg0-f49.google.com (HELO mail-qg0-f49.google.com) (209.85.192.49) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 29 Oct 2014 20:44:42 +0000 Received: by mail-qg0-f49.google.com with SMTP id z60so144977qgd.8 for ; Wed, 29 Oct 2014 13:44:40 -0700 (PDT) X-Received: by 10.224.131.137 with SMTP id x9mr20131801qas.74.1414615480769; Wed, 29 Oct 2014 13:44:40 -0700 (PDT) Received: from pike.twiddle.home (50-194-63-110-static.hfc.comcastbusiness.net. [50.194.63.110]) by mx.google.com with ESMTPSA id t11sm1744907qam.7.2014.10.29.13.44.39 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Oct 2014 13:44:40 -0700 (PDT) Message-ID: <545151B5.6040103@twiddle.net> Date: Wed, 29 Oct 2014 20:44: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: David Miller CC: libffi-discuss@sourceware.org Subject: Re: [PATCH 3/8] sparc: Rewrite everything References: <1414525555-21256-4-git-send-email-rth@twiddle.net> <20141029.141027.901195445453157818.davem@davemloft.net> <545147A9.9090401@twiddle.net> <20141029.161058.1101864756322678040.davem@davemloft.net> In-Reply-To: <20141029.161058.1101864756322678040.davem@davemloft.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2014/txt/msg00172.txt.bz2 On 10/29/2014 01:10 PM, David Miller wrote: > From: Richard Henderson > Date: Wed, 29 Oct 2014 13:01:45 -0700 > >> On 10/29/2014 11:10 AM, David Miller wrote: >>> Maybe I'm missing something? >> >> The two limits are in fact different. In gcc, see sparc_return_in_memory and >> sparc_pass_by_reference. > > My bad, thanks for clarifying. > > That's the only thing that caught my eye. I think for most v9 chips a > 'return' is slightly more expensive than a 'ret/restore'. 'return' is > good for saving an instruction when you can put something in that > delay slot, but if you can't then you might as well do 'ret/restore'. Ah right, thanks. The one other microarchitecture question I had was wrt call/ret paring. I was assuming that, for predition purposes, "ret" vs "jmp" must be based on the register used -- %i7 or %o7. Thus my call ... jmp %o7+const hopefully keeps any call/return prediction stack in sync? r~