Hi All,<div><br> </div><div>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.
</div><div><br> </div><div>IR will made some things easier and somethings harder.</div><div><br class="webkit-block-placeholder"></div><div>Good things:</div><div>   * valgrind is very tightly tied to the underlying architecture, bcgrind can be totally platform independent.
</div><div>   * Memory allocation is done with intrinsics, and will be very easy to keep track of. For a memory use analyser (memcheck).</div><div><br> </div><div>Bad things:</div><div>   * A cache profiler will be tricky, because we are quite abstracted from the hardware.
</div><div>     If a cache emulator was programmed, it could only give rough estimates of the cache</div><div>     miss rate.</div><div>   * 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.
</div><div><br class="webkit-block-placeholder"></div><div>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.
</div><div><br class="webkit-block-placeholder"></div><div>The question is, will this tool be useful to anyone? does anyone have insights into a good</div><div>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) ?
</div><div><br class="webkit-block-placeholder"></div><div>PS. </div><div>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.
</div>