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 :-) F Owen Anderson wrote:> Rodrigo, > > On Mar 20, 2009, at 8:41 AM, Rodrigo Dominguez wrote: >> 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. :-) > > 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 > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
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. :-) >> >> 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, 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>