GSoC09 - Port Valgrind to use LLVM

Hi,

Congratulations to LLVM for getting accepted to GSoC 2009!

I am a PhD candidate interested in participating this year. I have been
working on dynamic compilation (binary translation or BT) for multicore
architectures for a couple of years. I am familiar with the internals of
several BT frameworks (including open-source Valgrind).

I was looking at the ideas page for LLVM. I would like to know more about
"Miscellaneous Additions: Port Valgrind to use LLVM code generation and
optimization". Would it be possible to get in touch with the mentor for this
idea to learn more about it?

Thank you,

Rodrigo Dominguez
http://www.ece.neu.edu/~rdomingu/

Rodrigo,

Congratulations to LLVM for getting accepted to GSoC 2009!

I am a PhD candidate interested in participating this year. I have been
working on dynamic compilation (binary translation or BT) for multicore
architectures for a couple of years. I am familiar with the internals of
several BT frameworks (including open-source Valgrind).

I was looking at the ideas page for LLVM. I would like to know more about
"Miscellaneous Additions: Port Valgrind to use LLVM code generation and
optimization". Would it be possible to get in touch with the mentor for this
idea to learn more about it?

I think I'm the one who put that suggestion up, so I suppose I should speak to it. :slight_smile:

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.

--Owen

Hi,

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".

Regards and let's hope this project is accepted :slight_smile:

   F

Owen Anderson 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.

I think I'm the one who put that suggestion up, so I suppose I should
speak to it. :slight_smile:

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?

Andrew.

Hi,

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. :slight_smile:

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 :wink:

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