[LLVMdev] valgrind for BitCode

Andy Kitchen agimbleinthewabe at gmail.com
Wed Aug 8 08:12:14 PDT 2007


Hi All,

I'm currently learning llvm, for later use with a research project. I
thought a good way to learn would be to use it in a small to medium sized
project. A valgrind like tool for BitCode would work quite nicely.


IR will made some things easier and somethings harder.

Good things:
   * valgrind is very tightly tied to the underlying architecture, bcgrind
can be totally platform independent.
   * Memory allocation is done with intrinsics, and will be very easy to
keep track of. For a memory use analyser (memcheck).


Bad things:
   * A cache profiler will be tricky, because we are quite abstracted from
the hardware.
     If a cache emulator was programmed, it could only give rough estimates
of the cache
     miss rate.
   * When the bc code calls into native libraries it will be a black box.
There are work arounds we can use, to catch things like memory allocation,
but they become icky and platform dependent.

The basic idea, will be to follow the llvm style, and create a new
interpreter, based on the old one that will have a plug-in architecture, and
allow analysis tools to be plugged in.

The question is, will this tool be useful to anyone? does anyone have
insights into a good
plug-in architecture? (I was thinking call-backs can be registered with each
IR operation and some state information) and, does anyone want to have a
hand in cutting the code :0) ?

PS.
Also, I know nothing about OpenMP, but perhaps we could do multithreaded
memory access analysis which is something that hasn't really been done
much/well before. The great thing about valgrind is that it can tell you,
per-bit, if you have allocated the memory and if it is initialised. This
could be done for threads as-well.  (ie. how many different threads access
this memory, where was this memory is allocated, is there an associated
lock?) If people can associate memory regions with locks, we can make sure
that no thread _ever_ access synchronised memory without a lock. Although
now that I think of it, you could do this with valgrind too.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070809/595465e5/attachment.html>


More information about the llvm-dev mailing list