<div>Hi,</div><div><br></div><div><div class="gmail_quote">On Fri, Apr 3, 2009 at 17:37, Andrew Haley <span dir="ltr"><<a href="mailto:aph@redhat.com" target="_blank">aph@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>Filipe Cabecinhas wrote:<br>
<br>
> Just a thought... How are you going to port llvm so it doesn't use libc?<br>
> Valgrind uses the same resources as the running program, so it can't use<br>
> the system libc's malloc nor any other functions so it doesn't get<br>
> "confused".<br>
<br>
</div>I think you could to put LLVM into a different process.<br>
<div></div></blockquote><div>Ah, yes... But... You're thinking about using shared memory or sockets? Maybe that wouldn't give you the speed bump you'd like... But it would be interesting either way...</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>>> I think I'm the one who put that suggestion up, so I suppose I should<br>


>> speak to it. :-)<br>
>><br>
>> The concept would be to implement a conversion from Valgrind's<br>
>> internal IR to LLVM IR, and then employing the LLVM JIT system to<br>
>> execute the instrumented program.  In theory, at least, this shouldn't<br>
>> be too tough, as Valgrind already uses an SSA-based IR.  While there's<br>
>> almost certainly more overhead involved in doing this, it may be<br>
>> worthwhile if the instrumented program is long-running.<br>
>><br>
>> I'm not an expert on Valgrind, but I've been working on LLVM for while<br>
>> now, and could mentor at least the LLVM part of this.<br>
<br>
</div>Have the Valgrind people been approached with this idea?<br></blockquote></div><br></div><div><span style="color:rgb(136, 136, 136)"><span style="color:rgb(0, 0, 0)">Not that I remember... And a quick look at the mailing list's archives confirms that.</span><br>

</span></div><div><br></div><div>I don't know that much about LLVM's IR to speak about it but I know of another person that knows a bit of both IRs reads this list ;-)</div><div><br></div><div>But mention it in valgrind's list, it's an interesting idea (although I don't know if it's worth it... Code generation isn't valgrind's biggest slodown... The tool's bookkeeping are much more demanding (That's how you get the "10x-100x slower" figures).</div>

<div><br></div><div>Run a program with the tool nullgrind, taking into account the bookkeeping VEX (the code reading and generation library) needs to do and try to see if it's worth it.</div><div><br></div><div>Regards,</div>
<div><br></div><div>  F</div><div><br></div>