On Thu, Nov 01, 2012 at 10:01:31AM +0400, Dmitry Vyukov wrote:
> > For gimplification context, see above, would be better to just
> > emit gimple directly.
> > For func_calls and func_mops, I believe why you need two variables instead
> > of just one, and why the function can't just return a bool whether
> > entry/exit needs to be instrumented or not.
> >
>
> It was useful for debugging and stats collection.
> We currently have something similar in llvm passes as well. E.g. when you
> add an additional optimization that eliminates some instrumentation, you
> need to see how much it helps.
But you are not using it anywhere but to decide if entry/exit should be
instrumented. Either you should put some message into the pass dump
if -fdump-tree-tsan{,0}, then you can just use that option and grep,
or for one time statistics gathering I think people are usually using
one-off hacks, some statistics variables, and fopen ("/tmp/somefile", "a");
fprintf (, ...); them either before exit or upon each change, then
gather that across say bootstrap/regtest and build of some interesting
packages. But such hacks shouldn't remain in gcc sources.
For how many __tsan_* calls have been emitted IMHO the easiest is just
to objdump -dr the resulting binary or shared library.
Jakub
