search for: timergroup

...rate application using the API, rather than through an llvm tool. Unfortunately, I'm having trouble seeing how to use the existing facilities without using opt. Setting llvm::TimePassesIsEnabled before creating the PassManagers doesn't seem to output anything, though it is making Timers and TimerGroups. Even if I call llvm::getPassTimer for one of the passes (and I do get a timer that is initialized), I can't figure out to get to its TimerGroup (TG is private, but if I use a debugger, I can get it and call printAll successfully). Looking through the code, TimerGroup's removeTimer (also c...

Thanks for the reply! Unfortunately, that seems to have the same effect as setting llvm::TimePassesIsEnabled myself, and all my same problems still apply as the TimingInfo's destructor (PassManager.cpp) is still never called. Running it in the debugger shows that TimerGroup's removeTimer method is never called, nor is it's destructor (but it's constructor is). On Wed, Jun 1, 2011 at 11:51 AM, Andrew Clinton <andrew at sidefx.com> wrote: > I got it working with this: > >     int          argc = 2; >     const char  *argv[2] = {"myopt...

...t; the API, rather than through an llvm tool. Unfortunately, I'm having > trouble seeing how to use the existing facilities without using opt. > Setting llvm::TimePassesIsEnabled before creating the PassManagers > doesn't seem to output anything, though it is making Timers and > TimerGroups. Even if I call llvm::getPassTimer for one of the passes > (and I do get a timer that is initialized), I can't figure out to get > to its TimerGroup (TG is private, but if I use a debugger, I can get > it and call printAll successfully). Looking through the code, > TimerGroup's...

...wrote: > Thanks for the reply! Unfortunately, that seems to have the same > effect as setting llvm::TimePassesIsEnabled myself, and all my same > problems still apply as the TimingInfo's destructor (PassManager.cpp) > is still never called. Running it in the debugger shows that > TimerGroup's removeTimer method is never called, nor is it's > destructor (but it's constructor is). > > On Wed, Jun 1, 2011 at 11:51 AM, Andrew Clinton<andrew at sidefx.com> wrote: >> I got it working with this: >> >> int argc = 2; >> con...

...t file control mechanism as the timing info, and works fine. The difference is that the "PrintStatistics()" function is global - it knows about all the statistics being kept. The output to stderr works fine. The equivalent printing control for the timing info is, however, bound to the TimerGroup class implemented in Support/Timer.h, .cpp. The relevant TimerGroup structures are static to the modules that define them, so there is no possibility of forcing the printing, like I can do with Statistics. :-( I haven't yet resorted to debugging LLVM in the JIT context to figure out what...

Hi, The code in Support/Timer.cpp has strangely inconsistent behavior for printAll vs printJSONValues. The former can work multiple times, while the latter calls prepareToPrintList(), which stops all timers, hence making all further attempts to print timers crash. Would it be possible not to call prepareToPrintList on printJSONValues, or at least make it optional? I am trying to serialize

...=10132== by 0x40CE62D: std::basic_ostream<char, std::char_traits<char> >& std::operator<< <std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*) (in /usr/lib/libstdc++.so.5.0.7) ==10132== by 0x86F9357: llvm::TimerGroup::removeTimer() (Timer.cpp:302) ==10132== by 0x86F8405: llvm::Timer::~Timer() (Timer.cpp:91) ==10132== by 0x8522B0A: std::pair<llvm::Pass* const, llvm::Timer>::~pair() ( PassManagerT.h:113) ==10132== by 0x8524260: void std::_Destroy<std::pair<llvm::Pass* const, llvm::Timer> &...