similar to: [LLVMdev] How best to time passes using the API instead of opt? Also, memory leaks when trying to do timing in the API.

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

I got it working with this: int argc = 2; const char *argv[2] = {"myopt", "-time-passes"}; cl::ParseCommandLineOptions(argc, (char **)argv, "my optimizer"); On 06/01/2011 01:19 PM, Michael Ilseman wrote: > I have some PassManagers, and I would like to output timing data for > how long each pass takes to execute with a separate

Oh, you probably also need to create a static llvm_shutdown_obj. On 06/01/2011 02:19 PM, Michael Ilseman 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

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

Our project runs LLVM in a JIT context, and we want to explore where the time is being spent in the various LLVM components. At the moment, we're running with a production version of 3.0, and expecting to upgrade to 3.1 soon. We noticed that clang and llc can display component timing using the -ftime-passes and -time-passes options respectively. A little poking around in the code revealed

Per subject, this patch adding an additional pass to handle vector operations; the idea is that this allows removing the code from LegalizeDAG that handles illegal types, which should be a significant simplification. There are still some issues with this patch, but does the approach look sane? -Eli -------------- next part -------------- Index: lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp

Thanks, that was a really helpful suggestion. If you're curious- here are some of the high cost areas: ===-------------------------------------------------------------------------=== DWARF Emission ===-------------------------------------------------------------------------=== Total Execution Time: 2.0117 seconds (2.0185 wall clock) ---User Time---

Here is some timing information from running the Zig standard library tests: $ ./zig test ../std/index.zig --enable-timing-info Name Start End Duration Percent Initialize 0.0000 0.0010 0.0010 0.0001 Semantic Analysis 0.0010 0.9968 0.9958 0.1192 Code Generation 0.9968 1.4000 0.4032

test/trace/Makefile.am | 1 test/trace/values.as | 63 +++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 64 insertions(+) New commits: diff-tree aaca94203d8a0ccb8feb32c0d57df3401fca0350 (from 987074e275ac77f8799e5fdf41890e8ef126b291) Author: Benjamin Otte <otte at gnome.org> Date: Sun Jun 17 12:56:42 2007 +0200 add values.as which provides some default values

Mikhail Zolotukhin <mzolotukhin at apple.com> writes: > Hi, > > When I recently was working on PR27157, I discovered a weird behavior > in our verifier, which made it impossible to discover the bug by using > '-verify-dom-info - verify' flags. This happens because, when we fully > unroll a loop, we remove it from the LPM loop queue along with all > analyses

Hi, Probably some of the leaks Valgrind reports are spurious, but the numbers seem to be significant enough to demand some attention: ==10132== LEAK SUMMARY: ==10132== definitely lost: 15,624 bytes in 558 blocks. ==10132== indirectly lost: 44,548 bytes in 1,591 blocks. ==10132== possibly lost: 37,576 bytes in 98 blocks. ==10132== still reachable: 1,336,876 bytes in 1,364 blocks.

Hi, I am writing a CallGraphSCCPass that uses LoopInfo which is a FunctionPass. However, doing so results in the following error. **** Unable to schedule 'Natural Loop Information' required by '......' **** Google led me to this page, where Devang Patel suggests implementing the addLowerLevelRequiredPasses in CGPassManager in a manner similar to MPPassManager.

On Wed, May 20, 2009 at 1:19 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > Per subject, this patch adding an additional pass to handle vector > operations; the idea is that this allows removing the code from > LegalizeDAG that handles illegal types, which should be a significant > simplification.  There are still some issues with this patch, but does > the approach

Right now, addPassesToEmitFile requires a FunctionPassManager. If I'm working with code that uses a plain PassManager and want it to generate code, are there any options better than doing this: /** * Wrapper class to run a FunctionPassManager as a ModulePass so that it * can be added to a plain PassManager. */ class FunctionPassManagerModulePass : public ModulePass { FunctionPassManager

Hi, Has anyone had any success with running different PassManagers on llvm::Modules they've already JITed and are executing? In detail: 1) getting the IR, in form of an llvm::Module 2) calling PassManager->run() on the module 3) calling getFunction() and getPointerToFunction() to JIT the module 4) executing the JITed code using the function pointer received in step 3 and then what I

Hi Philip, Thank you for your reply. So what would be the right way/API to write out-of-tree pass? I've been using *PassManagerBuilder*, which requires a callback refering to *legacy::PassManagerBase*, so I guess this will be no longer the good way to go? Son Tuan Vu On Tue, Apr 17, 2018 at 6:06 PM, Philip Pfaffe <philip.pfaffe at gmail.com> wrote: > Hi Son, > > I have an

Hi, I apologize in advance if this is not the correct place to ask these questions, but I would be very grateful for redirection to the appropriate list/docs if so. I've just started with LLVM in the last week or so, and have worked my way through the Kaleidoscope tutorial, the IR docs & programmers manual, plus a few of the examples; everything makes sense. But there's one

On Jun 21, 2007, at 4:13 PM, Dan Gohman wrote: > Right now, addPassesToEmitFile requires a FunctionPassManager. If I'm > working with code that uses a plain PassManager and want it to > generate > code, are there any options better than doing this: That's what FPPassManager does (include/llvm/PassManagers.h) . Function pass manager itself is a module level pass.

On Thu, Jun 21, 2007 at 04:37:14PM -0700, Devang Patel wrote: > > On Jun 21, 2007, at 4:13 PM, Dan Gohman wrote: > > > Right now, addPassesToEmitFile requires a FunctionPassManager. If I'm > > working with code that uses a plain PassManager and want it to > > generate > > code, are there any options better than doing this: > > That's what

Can anyone explain what this means? llvm/include/llvm/PassManagers.h:232: virtual void llvm::PMDataManager::addLowerLevelRequiredPass(llvm::Pass*, llvm::Pass*): Assertion `0 && "Unable to handle Pass that requires lower level Analysis pass"' failed. -Dave