search for: getexecutioncount

Another issue is with ProfileInfo::getExecutionCount(Function* F). Looking at the source code and results, I am seeing that it always returns the execution count of the entry basic block of the function. If the entry basic block is part of a loop, its execution count does not match the function invocation count. Is my assumption wrong, that Prof...

...ple matrix multiplication program. >> However, I noticed the following problems: >> >> 1. There is a warning message: "WARNING: profile information is >> inconsistent with the current program!" >> 2. The basic block counts (obtained from >> ProfileInfo::getExecutionCount(const BasicBlock*)) are correct only if I >> have compiled with "-disable-opt" or "-O0". When compiled with "-O3", >> the basic block counts are bogus values. >> 3. Some of the function counts (obtained from >> ProfileInfo::getExecutionCount(con...

...e method mentioned below. I tried it out on a simple matrix multiplication program. However, I noticed the following problems: 1. There is a warning message: "WARNING: profile information is inconsistent with the current program!" 2. The basic block counts (obtained from ProfileInfo::getExecutionCount(const BasicBlock*)) are correct only if I have compiled with "-disable-opt" or "-O0". When compiled with "-O3", the basic block counts are bogus values. 3. Some of the function counts (obtained from ProfileInfo::getExecutionCount(const Function*)) are incorrect i.e....

...I tried it out on a simple matrix multiplication program. > However, I noticed the following problems: > > 1. There is a warning message: "WARNING: profile information is > inconsistent with the current program!" > 2. The basic block counts (obtained from > ProfileInfo::getExecutionCount(const BasicBlock*)) are correct only if I > have compiled with "-disable-opt" or "-O0". When compiled with "-O3", > the basic block counts are bogus values. > 3. Some of the function counts (obtained from > ProfileInfo::getExecutionCount(const Function*)) a...

Hi Apala, On 11/09/12 11:20, apala guha wrote: > Is it possible to associate the branch frequency counts with the basic > blocks > in the intermediate representation? (e.g. Can I access basic block > frequencies in runOnFunction()?) Profile data really needs to be loaded at a module level, but once this has been done it can be accessed at any level (including function). In LLVM

....getNumber(); ProfileInfo &PI=getAnalysis<ProfileInfo>(); printf("\n%s:%d",__FILE__,__LINE__); fflush(stdout); const BasicBlock *BB=MBB.getBasicBlock(); if(BB!=NULL) printf("\nBB is not null"); //execcnt=getAnalysis<ProfileInfo>().getExecutionCount(BB); double execcnt=PI.getExecutionCount(BB); printf("\nBlock No=%d,ExecCnt=%f",blckno,execcnt); if(blckno!=-1) { oMsProfI[cnt].blockno=blckno; oMsProfI[cnt].execcnt=execcnt; cnt++; } } bool runOnMachineFunction(MachineFunction &MF) {...

Thanks Alastair. Is it possible to associate the branch frequency counts with the basic blocks in the intermediate representation? (e.g. Can I access basic block frequencies in runOnFunction()?) Also, I was able to produce a 'llvmprof.out' file. What is the format of this file? How can I parse it? Thanks. -Apala > > > On 09/07/2012 01:25 PM, Alastair Murray wrote: >

...I tried it out on a simple matrix multiplication program. > However, I noticed the following problems: > > 1. There is a warning message: "WARNING: profile information is > inconsistent with the current program!" > 2. The basic block counts (obtained from > ProfileInfo::getExecutionCount(const BasicBlock*)) are correct only if I > have compiled with "-disable-opt" or "-O0". When compiled with "-O3", > the basic block counts are bogus values. > 3. Some of the function counts (obtained from > ProfileInfo::getExecutionCount(const Function*)) a...

...ager the error went away. Unfortunately, I'm still seeing execution counts of -1 when I print them out in my MachineFunction pass. I access the profiling information at each MachineBasicBlock with the following code, where "bb" is a reference to the current MachineBasicBlock: PI->getExecutionCount(bb.getBasicBlock()) I believe I've integrated all the ProfileInfo* files from ToT with my LLVM-2.5 installation properly. The profiling code (and llvm-prof) seems to be working since llvm-prof is generating/printing the appropriate execution frequencies. Is there an obvious mistake that I co...

...tudent, who was going to work on static profiling for LLVM and will depend on any changes to this interface. The current ProfileInfo functions should also become virtual, and all other implementation details should be left to the subclass. Finally, I don't think the ignoreMissing parameter to getExecutionCount makes sense, instead the provider should always return -1 if it doesn't have the value, and clients should "do the right thing. 2. We shouldn't worry too much about preserving the functionality of the current llvm-prof tool, which uses the ProfileInfoLoader directly. llvm-prof should...

Hi all, as proposed in http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-February/020396.html I implemented the algorithm presented in [Ball94]. It only instruments the minimal number of edges necessary for edge profiling. The main changes introduced by this patch are: *) a interface compatible rewrite of ProfileInfo *) a cleanup of ProfileInfoLoader (some functionality in ProfileInfoLoader

Hi, Shuguang Feng wrote: > Does the current LLVM backend support reading in profile information > (without preserving across transformations)? An earlier poster Yes, it does. > http://groups.google.com/group/llvm-dev/browse_thread/thread/4bd65dbe84394bb7 > > noted that accessing execution counts in a MachineFunction pass (using > the BasicBlock* corresponding to the respective

...ntinel value of "-1" I see other bogus execution counts instead. For example, llvm-prof prints out the following as the most frequently executed basic block: ## %% Frequency 1. 4.80749% 18002906/3.74476e+08 inflate_stored() - bb20 but in my pass the frequency I see from PI->getExecutionCount (bb.getBasicBlock()) for the exact same BasicBlock (bb20 from function inflate_stored()) is 7.47821e-316. I verified that PI is indeed pointing to the same object created in llc.cpp with the following gdb trace: Breakpoint 1, main (argc=11, argv=0xbfffd394) at <path to llvm>/tools/ llc/llc....

Hi, Does the current LLVM backend support reading in profile information (without preserving across transformations)? An earlier poster http://groups.google.com/group/llvm-dev/browse_thread/thread/4bd65dbe84394bb7 noted that accessing execution counts in a MachineFunction pass (using the BasicBlock* corresponding to the respective MachineBasicBlock) returned 0 for all blocks. Running llc with

...d on > any changes to this interface. Yes, I thought so, I will try to do this quick. > The current ProfileInfo functions should also become virtual, and all other > implementation details should be left to the subclass. > > Finally, I don't think the ignoreMissing parameter to getExecutionCount makes > sense, instead the provider should always return -1 if it doesn't have the > value, and clients should "do the right thing. Maybe, its of course always possibile to have custom wrappers that perform this sort of task if necessary... > 2. We shouldn't worry too much ab...

Hello LLVM, Can you suggest a good way to use the loops and induction variable passes to map loop exiting BasicBlocks to InductionVariables. That is, can we use these tools to identify the loop condition. What i have tried Function Pass: foreach BB if(terminal is loop exit of containing loop) trace back to instruction producing the cond that the branch branches on -

Shuguang Feng wrote: >> What does "llc -debug-pass=Structure" say? Is the ProfileLoaderPass >> really the last pass to touch the ProfileInfo before you are using it? > > Below is the sequence of passes that I see. Although the > NoProfileInfo pass is being run, it should be subsequently overridden > by ProfileInfoLoaderPass (LoaderPass) correct? Yes. >

...; Unfortunately, I'm still seeing execution counts of -1 when I print > them out in my MachineFunction pass. I access the profiling > information at each MachineBasicBlock with the following code, where > "bb" is a reference to the current MachineBasicBlock: > > PI->getExecutionCount(bb.getBasicBlock()) What does "llc -debug-pass=Structure" say? Is the ProfileLoaderPass really the last pass to touch the ProfileInfo before you are using it? Also, does bb.getBasicBlock() for sure always returns a valid block refrerence? You are getting the PI by getAnalysis<Profil...