|
From: Nuno L. <nun...@sa...> - 2008-03-11 23:41:45
|
> http://www.valgrind.org/docs/valgrind2007.pdf has some info on > optimisations performed in section 3.7. Note especially that there are > two optimisation phases. You'll want to read the surrounding sections > (and probably the whole paper) to make sense of it. > > VEX/priv/ir/iropt.c is the main file controlling Vex optimisation, I > believe. It has this comment near the top: > > The comments in VEX/pub/libvex_ir.h is the best documentation for Vex. > > As the Valgrind paper says, these are fairly heavyweight optimisations for > a binary translation system. You could try to do some more compiler-style > optimisations, but I think the scope for improvement there is not so > great. But I could be wrong -- Julian, what do you think? Uhm, it seems that most easy optimizations are already implemented, as I would expect. Anyway I'll take a closer look (maybe next week) to what is implemented to see if we have any chance do improve anything at all. Inter-block optimizations (e.g. inlining, GCSE, ...) would be really cool, but I'm not sure how Vex is suited for that. > A very interesting project you could be try would be to implement chaining > for Vex -- the Valgrind paper (above) talks about this. (Section 2.3.6 of > http://www.valgrind.org/docs/phd2004.pdf discusses the old implementation > of chaining that was in pre-Vex Valgrind -- you can see the actual > implementation in Valgrind 2.4.1 at > http://www.valgrind.org/downloads/old.html.) Sounds interesting, but maybe this requires too much valgrind internals knowledge, but I'll take a look into this as well. > An important question you should consider early is what your goals are. > More specifically, are you trying to speed up Valgrind's code when no > instrumentation is present? In one way, that's the obvious thing to do, > but it's also the least interesting thing to do (the paper talks about > this in section 5.4). A more interesting thing is to speed up any of the > real existing tools, especially Memcheck, since that's the most widely > used. Yes, but I'm not sure I can justify such a project about dynamic program analysis in a virtual execution class. The class is targeted at dynamic binary translation, binary interpretation, intra-block optimizations, virtualization, and so on. > As for giving the code you develop back, there's a complication -- Julian > is the sole author and thus owns the copyright for the Vex part of > Valgrind. This means that accepting external contributions for Vex is more > complicated than the rest of Valgrind. He might have more to add. OK, we can take care of the copyright stuff later if we come up with something useful. Thanks, Nuno |