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

[Blue Swirl]

On Fri, May 6, 2011 at 7:38 PM, Paul Brook <address@hidden> wrote:
>> On Fri, May 6, 2011 at 5:09 PM, Paul Brook <address@hidden> 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.

>> > Maybe better would be to explicitly pass a pointer the fp status. That
>> > way you don't even need separate VFP and NEON variants of these
>> > routines.
>>
>> It would be nice to have generic float functions callable directly as
>> TCG helper.
>
> Possibly.  I'd have to look quite a bit closer to determine whether exposing
> the generic float functions is useful in practice, or if you still end up
> needing wrappers in most cases for most targets.  Adding "native" floating
> point support to the TCG interface is also a possibility.  In practice this
> might end up as wrappers around helper functions, but might provide a nicer
> programming interface.
>
> Paul
>