On Sun, May 08, 2011 at 01:32:34PM +0300, Blue Swirl wrote: > 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. >
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 aurel...@aurel32.net http://www.aurel32.net