I tried getting profile data from LLVM 3.1, using the 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. they do not equal the number of times the function was invoked. Can someone please explain why I am experiencing the above problems? Thanks in advance! -Apala On 09/12/2012 09:20 PM, Alastair Murray wrote:> 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 3.1 ProfileInfo stores block execution frequencies (use > -profile-loader). > > For LLVM svn you can look at BlockFrequencyInfo, which I generates its > data from BranchFrequencyInfo, which in turn uses the branch weight > metadata (set by -profile-metadata-loader). I haven't actually tried > this though, so I'm not sure how accurately the block frequencies are > maintained. > > >> Also, I was able to produce a 'llvmprof.out' file. What is the format of >> this file? How can I parse it? > > Very roughy the format of the file is lots of unsigned integers. > -profile-loader or -preofile-metadata-loader will parse it for you. > Parsing outside of LLVM is tricky as it relies on exact ordering of > basic blocks. > > Regards, > Alastair.
Apala- At which stage are you doing -insert-edge-profiling or similar ? My guess is if you do that early the opts/inline coming later at -O3 will mutate the cfg(s) causing errors. You should use -insert-edge-profiling without opts and call opt -O3 during the -profile-metadata-loader step. -dibyendu -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of apala guha Sent: Wednesday, September 19, 2012 12:34 AM To: Alastair Murray Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] counting branch frequencies I tried getting profile data from LLVM 3.1, using the 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. they do not equal the number of times the function was invoked. Can someone please explain why I am experiencing the above problems? Thanks in advance! -Apala On 09/12/2012 09:20 PM, Alastair Murray wrote:> 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 3.1 ProfileInfo stores block execution frequencies (use > -profile-loader). > > For LLVM svn you can look at BlockFrequencyInfo, which I generates its > data from BranchFrequencyInfo, which in turn uses the branch weight > metadata (set by -profile-metadata-loader). I haven't actually tried > this though, so I'm not sure how accurately the block frequencies are > maintained. > > >> Also, I was able to produce a 'llvmprof.out' file. What is the format >> of this file? How can I parse it? > > Very roughy the format of the file is lots of unsigned integers. > -profile-loader or -preofile-metadata-loader will parse it for you. > Parsing outside of LLVM is tricky as it relies on exact ordering of > basic blocks. > > Regards, > Alastair._______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Hi Apala, Dibyendu is correct that this is likely due to pass order, but things get a bit complicated with -O[1-9] or -std-compile-opts as they insert early passes *before* the profiling code. I recommend that you use identical optimizations to insert instrumentation and to load the profiling data. E.g.: opt -insert-edge-profiling -O3 foo.bc -o foo.2.bc opt -profile-loader -O3 foo.bc -o foo.opt.bc (The same applies to -profile-metadata-loader.) The -O3 on the first line seems pointless, but without it the CFG will be different (due to the early passes it inserts which run before any user specified passes). I've been thinking about submitting a patch to also include profile passes in the early passes (it they are turned on), but that seems quite limiting (a user may want to run them after other passes). This should fix all your problems (I hope!). Problem 1 means the program CFG does not match and thus the profiling data is basically gibbberish (hence problems 2 and 3). Perhaps that is another patch: fail on this condition rather than just warn. Hope this helps, Alastair. On 18/09/12 15:03, apala guha wrote:> I tried getting profile data from LLVM 3.1, using the 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. they > do not equal the number of times the function was invoked. > > Can someone please explain why I am experiencing the above problems? > Thanks in advance! > > -Apala > > > > On 09/12/2012 09:20 PM, Alastair Murray wrote: >> 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 3.1 ProfileInfo stores block execution frequencies (use >> -profile-loader). >> >> For LLVM svn you can look at BlockFrequencyInfo, which I generates its >> data from BranchFrequencyInfo, which in turn uses the branch weight >> metadata (set by -profile-metadata-loader). I haven't actually tried >> this though, so I'm not sure how accurately the block frequencies are >> maintained. >> >> >>> Also, I was able to produce a 'llvmprof.out' file. What is the format of >>> this file? How can I parse it? >> >> Very roughy the format of the file is lots of unsigned integers. >> -profile-loader or -preofile-metadata-loader will parse it for you. >> Parsing outside of LLVM is tricky as it relies on exact ordering of >> basic blocks. >> >> Regards, >> Alastair. > >
Can we not run the -insert-edge-profiling and -profile-loader passes at the beginning of the opt? Orthogonal point is, is it worth doing any optimizations when -insert-edge-profiling is specified on command line? -Prashantha -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Alastair Murray Sent: Wednesday, September 19, 2012 7:19 PM To: apala guha Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] counting branch frequencies Hi Apala, Dibyendu is correct that this is likely due to pass order, but things get a bit complicated with -O[1-9] or -std-compile-opts as they insert early passes *before* the profiling code. I recommend that you use identical optimizations to insert instrumentation and to load the profiling data. E.g.: opt -insert-edge-profiling -O3 foo.bc -o foo.2.bc opt -profile-loader -O3 foo.bc -o foo.opt.bc (The same applies to -profile-metadata-loader.) The -O3 on the first line seems pointless, but without it the CFG will be different (due to the early passes it inserts which run before any user specified passes). I've been thinking about submitting a patch to also include profile passes in the early passes (it they are turned on), but that seems quite limiting (a user may want to run them after other passes). This should fix all your problems (I hope!). Problem 1 means the program CFG does not match and thus the profiling data is basically gibbberish (hence problems 2 and 3). Perhaps that is another patch: fail on this condition rather than just warn. Hope this helps, Alastair. On 18/09/12 15:03, apala guha wrote:> I tried getting profile data from LLVM 3.1, using the 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. they > do not equal the number of times the function was invoked. > > Can someone please explain why I am experiencing the above problems? > Thanks in advance! > > -Apala > > > > On 09/12/2012 09:20 PM, Alastair Murray wrote: >> 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 3.1 ProfileInfo stores block execution frequencies (use >> -profile-loader). >> >> For LLVM svn you can look at BlockFrequencyInfo, which I generates its >> data from BranchFrequencyInfo, which in turn uses the branch weight >> metadata (set by -profile-metadata-loader). I haven't actually tried >> this though, so I'm not sure how accurately the block frequencies are >> maintained. >> >> >>> Also, I was able to produce a 'llvmprof.out' file. What is the format of >>> this file? How can I parse it? >> >> Very roughy the format of the file is lots of unsigned integers. >> -profile-loader or -preofile-metadata-loader will parse it for you. >> Parsing outside of LLVM is tricky as it relies on exact ordering of >> basic blocks. >> >> Regards, >> Alastair. > >_______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Thanks everyone for the replies. After some experimentation, I found that the order in which the passes are specified matters: opt -O3 -profile-loader matmult.bc -o matmult.opt.bc (works) opt -profile-loader -O3 matmult.bc -o matmult.opt.bc (does not work) Also, I am able to avoid the inconsistency warning only for optimization levels -O3 and -O2. I get that warning when using -O1 and -disable-opt. Anyone else have this experience? Or, any ideas why the above might happen? Thanks. -Apala On 09/19/2012 08:49 AM, Alastair Murray wrote:> Hi Apala, > > Dibyendu is correct that this is likely due to pass order, but things > get a bit complicated with -O[1-9] or -std-compile-opts as they insert > early passes *before* the profiling code. > > I recommend that you use identical optimizations to insert > instrumentation and to load the profiling data. > > E.g.: > opt -insert-edge-profiling -O3 foo.bc -o foo.2.bc > opt -profile-loader -O3 foo.bc -o foo.opt.bc > > (The same applies to -profile-metadata-loader.) The -O3 on the first > line seems pointless, but without it the CFG will be different (due to > the early passes it inserts which run before any user specified passes). > > I've been thinking about submitting a patch to also include profile > passes in the early passes (it they are turned on), but that seems > quite limiting (a user may want to run them after other passes). > > This should fix all your problems (I hope!). Problem 1 means the > program CFG does not match and thus the profiling data is basically > gibbberish (hence problems 2 and 3). Perhaps that is another patch: > fail on this condition rather than just warn. > > Hope this helps, > Alastair. > > On 18/09/12 15:03, apala guha wrote: >> I tried getting profile data from LLVM 3.1, using the 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. they >> do not equal the number of times the function was invoked. >> >> Can someone please explain why I am experiencing the above problems? >> Thanks in advance! >> >> -Apala >> >> >> >> On 09/12/2012 09:20 PM, Alastair Murray wrote: >>> 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 3.1 ProfileInfo stores block execution frequencies (use >>> -profile-loader). >>> >>> For LLVM svn you can look at BlockFrequencyInfo, which I generates its >>> data from BranchFrequencyInfo, which in turn uses the branch weight >>> metadata (set by -profile-metadata-loader). I haven't actually tried >>> this though, so I'm not sure how accurately the block frequencies are >>> maintained. >>> >>> >>>> Also, I was able to produce a 'llvmprof.out' file. What is the >>>> format of >>>> this file? How can I parse it? >>> >>> Very roughy the format of the file is lots of unsigned integers. >>> -profile-loader or -preofile-metadata-loader will parse it for you. >>> Parsing outside of LLVM is tricky as it relies on exact ordering of >>> basic blocks. >>> >>> Regards, >>> Alastair. >> >> >