similar to: [LLVMdev] Block profiling in LLVM

Dear All LLVM Users,   I'm new to LLVM environment. I want to perform basic block profiling. I'm using LLVM3.1 I tried it with a simple 'c' code to find Max.No,  mentioned below. ----------------------------------------------------------------------------------------------------------------------------------------- #include <stdio.h> int main() {  unsigned int i,temp;  

Dear All, I'm using LLVM2.9 for profiling basic block frequency. I'm using following commands. rdpatel55 at ubuntu:~$ llvm-gcc -emit-llvm -O0 -c -o adpcm.bc adpcm.c rdpatel55 at ubuntu:~$ llvm-gcc -emit-llvm -O0 -c -o rawcaudio.bc rawcaudio.c rdpatel55 at ubuntu:~$ llvm-link -o main.bc rawcaudio.bc adpcm.bc rdpatel55 at ubuntu:~$ opt -q -f -insert-edge-profiling -o main.inst main.bc

Hi all, In light of the expected removal of ProfileInfo this is a request for comments on the next few items that I now plan to work on for GSoC. Planned tasks: #0 Add support for determining branch weight metadata by profiling At the absolute minimum this will require writing a new profile loader which will set branch weight metadata based on profiling data. #1 Optionally use profiling

Hi gang, time for my weekly confusion... (I'm trying not to bombard the board with questions) The thing that's on my mind at the moment (there's some backend-stuff that I'm just working my way though) is that I'm not getting very far when trying to get LLVM to profile code - I'm looking for nothing more special than list of how many times each basic block has been called

Hi all, Attached is a draft patch to use profiling data to set branch weight metadata. I'm not formally submitting this as a patch yet as it does not make much sense to add it before ProfileInfo etc. is removed. I am, however, interested in making sure this is the correct approach to be taking, or any other feedback. (Also, there are a few TODO notes in there which would not be in the

Hi Alastair, Your patch looks great. I am new on this part of llvm. Why do we want to get rid of ProfileInfo? Is there any email thread related to this? I understand that we want to setBranchWeightMetadata from the profiling data generated by -insert-edge-profiling. I thought the existing loader can parse the profiling data and map the data to the IR, and only the setting of metadata is missing.

Hi Alastair, Thank you so much for the information on the tools. Actually, I need to analyze which sections of code are prone to misses and mis predicts, and would have to eventually instrument the code. I was able to instrument and call an external function, but faced an issue while passing an argument to the function. I am following EdgeProfiling.cpp but couldn't figure out the problem.

Hi, @Alastair: Thanks a bunch for explaining this so well. I was able to write a simple profiler, and run it. I need to profile the code for branches (branch mis predicts simulation), load/store instructions (for cache hits/miss rate), and a couple of other things and therefore, would need to instrument the code. However, I would like to know if writing the output to a file would increase the

Hi, I am using Path Profiling to path profile a C code. I'm using this commands: $ llvm-gcc -c -emit-llvm file.c -o file.bc $ opt --insert-hotpath-profiling file.bc -o file.ins.bc $ llc -march=x86 file.ins.bc -o file.ins.s $ gcc -I llvm2.9/runtime/PathProfling.c -I llvm2.9/runtime/CommonProfiling.c $ ./a.out This will give me path profile of of program in 'llvmpro.out' to decode

Hi Alastair, In addition to your planned tasks, you might want to put in some work to ensure branch probabilities are not lost during optimization. One known issue is LLVM optimizer can turn branchy code into switch statements and it would completely discard probability. Here is a simple example: static void func2(int N, const int *a, const int *b, int *c) __attribute__((always_inline)); void

On Sun, Jul 15, 2012 at 8:32 AM, Alastair Murray <alastairmurray42 at gmail.com > wrote: > Hi Chandler, > > I'm a GSoC student working on profiling support (mentor CC'ed). I'm no > stranger to the issues with the current system: my original proposal was > written without knowledge of the limitations. This is why this list > hasn't heard much from me yet.

On Wed, Feb 25, 2015 at 10:52 AM, Philip Reames <listmail at philipreames.com> wrote: > On 02/24/2015 03:31 PM, Diego Novillo wrote: > > > We (Google) have started to look more closely at the profiling > infrastructure in LLVM. Internally, we have a large dependency on PGO to get > peak performance in generated code. > > Some of the dependencies we have on profiling

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

Hi Silky, On 14/01/13 01:47, Silky Arora wrote: > I need to profile the code for branches (branch mis predicts > simulation), load/store instructions (for cache hits/miss rate), and a > couple of other things and therefore, would need to instrument the code. > However, I would like to know if writing the output to a file would > increase the execution time, or is it the profiling

Hi Silky, Sorry for the slow reply. You probably already fixed this, but just in case I'll reply anyway. Comments inline below On 15/01/13 19:38, SArora wrote: > Hi Alastair, > Thank you so much for the information on the tools. Actually, I need to > analyze which sections of code are prone to misses and mis predicts, and > would have to eventually instrument the code. >

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

Hi Alok, On 16/07/12 12:41, #ALOK PRAKASH# wrote: > I have been using the Profile.pl and the related passes and > optimizations for about 4 years now. With every new release lately, the > support for the profile scripts and their framework seemed to be > downgrading. Hence, I used my own tiny one line fixes to keep them > working. I offered to send these small patches to keep these

Hi, I am new to LLVM, and would like to write a dynamic profiler, say which prints out the load address of all the load instructions encountered in a program. >From what I could pick up, edge-profiler.cpp increments a counter dynamically which is somehow dumped onto llvmprof.out by profile.pl Could anyone explain me how this works? Can I instrument the code to dump out the load addresses or

There is code that does this for older versions of LLVM. I believe it is in the giri project in the LLVM SVN repository. I can look into more details when I get back from vacation. Swarup may also be able to provide information on the giri code. -- John T. ________________________________________ From: llvmdev-bounces at cs.uiuc.edu [llvmdev-bounces at cs.uiuc.edu] on behalf of Silky Arora

Alright, I'm ready to nuke it. Last chance to say stop. For context of others, this has come up repeatedly: no one we know of is using EdgeProfiling.cpp, PathProfiling.cpp, and the lib/Analysis/Profile*Pass.cpp collection of tools. They haven't been updated since 2012 when Alastair Murray looked into this stuff, and both current efforts towards PGO are essentially *totally* different