From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LCMdZ-0007z4-DQ for qemu-devel@nongnu.org; Mon, 15 Dec 2008 18:14:05 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LCMdX-0007wd-GW for qemu-devel@nongnu.org; Mon, 15 Dec 2008 18:14:04 -0500 Received: from [199.232.76.173] (port=32800 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LCMdX-0007w7-7e for qemu-devel@nongnu.org; Mon, 15 Dec 2008 18:14:03 -0500 Received: from mx20.gnu.org ([199.232.41.8]:59596) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LCMdW-0001DP-Q3 for qemu-devel@nongnu.org; Mon, 15 Dec 2008 18:14:02 -0500 Received: from mail.codesourcery.com ([65.74.133.4]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LCMdT-0006N0-Fz for qemu-devel@nongnu.org; Mon, 15 Dec 2008 18:13:59 -0500 From: Paul Brook Subject: Re: [Qemu-devel] [PATCH 03/42] target-ppc: add gen_avr_ptr function. Date: Mon, 15 Dec 2008 23:13:55 +0000 References: <1229307315-16807-1-git-send-email-froydnj@codesourcery.com> <1229307315-16807-4-git-send-email-froydnj@codesourcery.com> <20081215221643.GG8523@volta.aurel32.net> In-Reply-To: <20081215221643.GG8523@volta.aurel32.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200812152313.56071.paul@codesourcery.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Nathan Froyd , Aurelien Jarno > I am still pondering what is the better solution between passing a > pointer to an avr register or the avr register number. > > Does someone has an opinion about that? FWIW it was probably me recommended passing things by value. It feels cleaner because with pointers it's pretty much impossible to TCG to tell what's going on. I was also hoping that it would mean many of the helpers could be shared between AltiVec and SPE. On closer inspection it looks like there aren't really that many interesting opportunities for this. On ARM NEON there are two different vector lengths, and registers overlap in interesting ways, so we need most of the splitting and iteration stuff anyway. AltiVec and SSE are more restricted instruction sets, so I guess there's probably less benefit. Paul