Re: [Qemu-devel] [PATCH 4/7] target-arm: Refactor int-float conversions

[Aurelien Jarno <aurelien@aurel32.net>]

On Sun, May 08, 2011 at 01:32:34PM +0300, Blue Swirl wrote:
> On Fri, May 6, 2011 at 7:38 PM, Paul Brook <paul@codesourcery.com> wrote:
> >> On Fri, May 6, 2011 at 5:09 PM, Paul Brook <paul@codesourcery.com> 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