[LLVMdev] GSoC09 - Port Valgrind to use LLVM

[Filipe Cabecinhas]

Hi,

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
confirms that.

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.

Regards,

  F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090403/5696c963/attachment.html>