<div dir="ltr">For (3), would something like making all statements conditional (like LoadG, StoreG, and Exit are) do, or are we talking about something more complex?</div><div class="gmail_extra"><br><br><div class="gmail_quote">

On Wed, Feb 26, 2014 at 7:16 AM, Julian Seward <span dir="ltr"><<a href="mailto:jseward@acm.org" target="_blank">jseward@acm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
On 02/26/2014 12:23 PM, Kirill Batuzov wrote:<br>
<br>
I tend to agree with Kirill.  It would be great to make Valgrind/Memcheck<br>
faster, and there are certainly ways to do that, but using LLVM is not<br>
one of them.<br>
<div class=""><br>
> Second, in DBT you translate code in small portions like basic blocks,<br>
> or extended basic blocks. They have very simple structure. There is no<br>
> loops, there is no redundancy from translation high level language to<br>
> low level. There is nothing good sophisticated optimizations can do<br>
> better then very simple ones.<br>
<br>
</div>Yes.  One of the problems of the "Let's use LLVM and it'll all go much<br>
faster" concept is that it lacks a careful analysis of what makes Valgrind<br>
(and QEMU, probably) run slowly in the first place.<br>
<br>
As Kirill says, the short blocks of code that V generates make it<br>
impossible for LLVM to do sophisticated loop optimisations etc.<br>
Given what Valgrind's JIT has to work with -- straight line pieces<br>
of code -- it generally does a not-bad job of instruction selection<br>
and register allocation, and I wouldn't expect that substituting LLVM's<br>
implementation thereof would make much of a difference.<br>
<br>
What would make Valgrind faster is<br>
<br>
(1) improve the caching of guest registers in host registers across<br>
    basic block boundaries.  Currently all guest registers cached in<br>
    host registers are flushed back into memory at block boundaries,<br>
    and no host register holds any live value across the boundary.<br>
    This is simple but very suboptimal, creating large amounts of<br>
    memory traffic.<br>
<br>
(2) improve the way that the guest program counter is represented.<br>
    Currently it is updated before every memory access, so that if an<br>
    unwind is required, it is possible.  But this again causes lots of<br>
    excess memory traffic.  This is closely related to (1).<br>
<br>
(3) add some level of control-flow if-then-else support to the IR, so<br>
    that the fast-case paths for the memcheck helper functions<br>
    (helperc_LOADV64le etc) can be generated inline.<br>
<br>
(4) Redesign Memcheck's shadow memory implementation to use a 1 level<br>
    map rather than 2 levels as at present.  Or something more<br>
    TLB-like.<br>
<br>
I suspect that the combination of (1) and (2) causes processor write<br>
buffers to fill up and start stalling, although I don't have numbers<br>
to prove that.  What _is_ very obvious from profiling Memcheck using<br>
Cachegrind is that the generated code contains much higher proportion<br>
of memory references than "normal integer code".  And in particular<br>
it contains perhaps 4 times as many stores as "normal integer code".<br>
Which can't be a good thing.<br>
<br>
(3) is a big exercise -- much work -- but potentially very beneficial.<br>
(4) is also important if only because we need a multithreaded<br>
implementation of Memcheck.  (1) and (2) are smaller projects and would<br>
constitute a refinement of the existing code generation framework.<br>
<div class=""><br>
> In conclusion I second what have already been said: this project sounds<br>
> like fun to do, but do not expect much practical results from it.<br>
<br>
</div>The above projects (1) .. (4) would also be fun :-) and might generate more<br>
immediate speedups for Valgrind.<br>
<div class="HOEnZb"><div class="h5"><br>
J<br>
<br>
<br>
------------------------------------------------------------------------------<br>
Flow-based real-time traffic analytics software. Cisco certified tool.<br>
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer<br>
Customize your own dashboards, set traffic alerts and generate reports.<br>
Network behavioral analysis & security monitoring. All-in-one tool.<br>
<a href="http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk" target="_blank">http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk</a><br>
_______________________________________________<br>
Valgrind-developers mailing list<br>
<a href="mailto:Valgrind-developers@lists.sourceforge.net">Valgrind-developers@lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/valgrind-developers" target="_blank">https://lists.sourceforge.net/lists/listinfo/valgrind-developers</a><br>
</div></div></blockquote></div><br></div>