From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:50513) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QLNU2-00038Q-Tw for qemu-devel@nongnu.org; Sat, 14 May 2011 18:38:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QLNU1-0003Eh-J6 for qemu-devel@nongnu.org; Sat, 14 May 2011 18:38:50 -0400 Received: from hall.aurel32.net ([88.191.126.93]:51392) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QLNU1-0003Ec-Bk for qemu-devel@nongnu.org; Sat, 14 May 2011 18:38:49 -0400 Date: Sun, 15 May 2011 00:38:43 +0200 From: Aurelien Jarno Message-ID: <20110514223843.GF13600@volta.aurel32.net> References: <1304686095-30265-1-git-send-email-peter.maydell@linaro.org> <201105061509.37212.paul@codesourcery.com> <201105061738.09777.paul@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Subject: Re: [Qemu-devel] [PATCH 4/7] target-arm: Refactor int-float conversions List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: Peter Maydell , patches@linaro.org, Paul Brook , qemu-devel@nongnu.org On Sun, May 08, 2011 at 01:32:34PM +0300, Blue Swirl wrote: > On Fri, May 6, 2011 at 7:38 PM, Paul Brook wrote: > >> On Fri, May 6, 2011 at 5:09 PM, Paul Brook wrote: > >> >> The Neon versions of int-float conversions need their own helper > >> >> routines because they must use the "standard FPSCR" rather than the > >> >> default one. Refactor the helper functions to make it easy to add the > >> >> neon versions. While we're touching the code, move the helpers to > >> >> op_helper.c so that we can use the global env variable rather than > >> >> passing it as a parameter. > >> > > >> > IMO this is going in the wrong direction.  We should in aiming for less > >> > implicit accesses to cpu state, not more. > >> > >> Performance wise global env variable is faster and the register is > >> always available. > > > > Not entirely true.  Reserving the global env variable has significant cost, > > especially on hosts with limited register sets (i.e. x86).  It's also a rather > > fragile hack.  There's a fairly long history of nasy hacks and things that > > just don't work in this context.  For example you can't reliably include > > stdio.h from these files, and they often break if you turn optimization off, > > which makes debugging much harder than it should be. > > Even if we don't reserve the register, in many cases a corresponding > pointer to CPUState will be needed. But there will still be the > advantage that this temporary pointer can be discarded while the > globally reserved register is reserved forever. > > >> Do you mean that we should aim to get rid of special > >> status of global env, so that if no op uses it, it could be discarded > >> to free a register? > > > > That's already true for most of qemu.  IMO more interesting is being able to > > tell TCG that helpers don't mess with cpu state in opaque ways.  In theory > > it's already possible to do that manually. However that tends to be somewhat > > fragile, relying on careful maintenance and code code auditing, with mistakes > > triggering subtle hard-to-debug failures.  Much better to avoid the implicit > > global interface and make all helper arguments explicit. > > OK. This will be a major refactoring, but given the expected > performance increase, it should be done. > We might want to do it from the cleanliness point of view, but i really doubt we should expect performance increase from this (actually i think it will be the contrary). -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurelien@aurel32.net http://www.aurel32.net