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