On 05/04/2011 01:13 PM, Blue Swirl wrote: >> Sparc loses out on some TCG optimizations because of that, although >> to be fair the most effective of these are still in Aurlien's trees. > > Interesting. Which optimizations? What trees? How would you implement > the register windows then?
Constant propagation for one. This one in particular would allow the tcg backend to see full constants, rather than seeing the constant being built up from risc instructions. git://git.aurel32.net/qemu.git tcg-optimizations I have previously built on this to streamline the code generated for target load/store operations. We currently always force the address into a register and do the arithmetic on that. If we have the full constant for the address, we can push the parts of that constant into the TLB load etc. git://repo.or.cz/qemu/rth.git tcg-const-addr-1 As for how to implement the register windows... I'm not 100% sure. The easiest way is indeed to copy values to and fro a consolidated register file, as Max is doing here. I've also experimented briefly with extending TCG to handle "indirect" registers. Where the register values are consistent as far as the TCG optimizers are concerned, but when it comes time to expand the code, we perform the indirect read, just as you currently expand by hand ahead of time. I never got either solution totally working for sparc. r~
