On Sat, May 21, 2011 at 11:37:49AM +0200, Laurent Desnogues wrote: > On Sat, May 21, 2011 at 1:31 AM, Andreas Färber <andreas.faer...@web.de> > wrote: > [...] > > Has anyone evaluated reusing LLVM optimization passes for TCG? Or maybe > > GIMPL if there's an equivalent? > > IMHO the qemu_ld/st semantics and the size of TB blocks > will always limit the usefulness of more involved > optimizations than what already exists in QEMU. > > Basically qemu_ld/st ops prevent any code change across > them which make optimization opportunities rather low. > Considering they always take the fast path would surely > change the situation, but then the slow path would have to > be able to rebuild information; certainly possible, but > quite involved too :-)
Actually one way to improve this is to consider that the value in TCG registers should be in sync with the memory. This is the only needed thing to get the CPU state correct in case the slow path is taken and an exception is triggered. This is not something difficult to do, and already allow a few more optimizations accross the qemu_ld/st ops, though not as many as we want. However, given the current register allocator, qemu_ld/st ops have the good effect of saving globals back to their canonical location, and thus freeing some register. If you only sync them, you end up with all globals being free a lot later even if they are not used, which means plenty of suboptimal register spills. We definitely need to rewrite/improve the register allocator to save a global back to memory when it is not used later in the TB. I am currently working on that, I hope to have something ready soon. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
