On Mon, Oct 19, 2009 at 8:23 AM, <juha.riihim...@nokia.com> wrote: > > I think I have a couple of other fixes and patches on top of that as > well, but I'd rather wait until you get this bunch committed and then > format the patches against the new mainline so that they apply.
It's already been committed (the commit notification process is again dead). > On the subject of the new_tmp/dead_tmp, can you elaborate how critical > it is if there are resource leaks in the translator code, i.e. if some > of the temporary variables don't get marked dead? I suppose the > leakage would only affect the translation of the code block where it > appears? I found more leaks by introducing a new_tmp64/dead_tmp64 and > some other checkups to catch programming errors. Yes it would only affect one TB. The price would be a higher time spent in the TCG -> host code generation pass, since some parts are linear in the number of live temps. > Some of the generated tcg code is not very optimal, for example a > single vld4.8 instruction can generate over 250 tcg ops. I did some > optimizations and got it under 200 but do you think it could be an > issue that a single instruction can expand to so many tcg ops? I mean > besides the fact that it causes TBs for only one or two guest > instructions to be generated. Fabrice wrote this (tcg/README): Don't hesitate to use helpers for complicated or seldom used target intructions. There is little performance advantage in using TCG to implement target instructions taking more than about twenty TCG instructions. How applicable is it, I can't say. It'd probably be a good thing to benchmark the two versions, TCG vs helper. > Perhaps this would also be a good place and time to also ask whether > you would be interested in integrating support for OMAP3 in the QEMU > mainline? We have been developing and using it for several months now, > it's based on the work done by Yajin <ya...@vm-kernel.org> to support > the OMAP3 BeagleBoard hardware. We have added support for the Nokia > N900 system emulation as well. In my personal opinion the OMAP3 > emulation is in functionality on par with the existing OMAP2 > emulation, if not even more complete. I would certainly like to see that in mainline! Laurent
