[LLVMdev] GSoC09 - Port Valgrind to use LLVM
filcab at gmail.com
Fri Apr 3 11:49:35 PDT 2009
On Fri, Apr 3, 2009 at 17:37, Andrew Haley <aph at redhat.com> wrote:
> Filipe Cabecinhas wrote:
> > Just a thought... How are you going to port llvm so it doesn't use libc?
> > Valgrind uses the same resources as the running program, so it can't use
> > the system libc's malloc nor any other functions so it doesn't get
> > "confused".
> I think you could to put LLVM into a different process.
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...
>> I think I'm the one who put that suggestion up, so I suppose I should
> >> speak to it. :-)
> >> The concept would be to implement a conversion from Valgrind's
> >> internal IR to LLVM IR, and then employing the LLVM JIT system to
> >> execute the instrumented program. In theory, at least, this shouldn't
> >> be too tough, as Valgrind already uses an SSA-based IR. While there's
> >> almost certainly more overhead involved in doing this, it may be
> >> worthwhile if the instrumented program is long-running.
> >> I'm not an expert on Valgrind, but I've been working on LLVM for while
> >> now, and could mentor at least the LLVM part of this.
> Have the Valgrind people been approached with this idea?
Not that I remember... And a quick look at the mailing list's archives
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 ;-)
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).
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev