search for: codegenpgo

...ers2 pc1 counter1 pc2 counter2 pc3 counter3 ... I don't see a straightforward way to produce such data today because individual Instructions do not work as labels. But I think this can be supported in LLVM codegen. Here is a *raw* patch with comments, just to get the idea. Index: lib/CodeGen/CodeGenPGO.cpp =================================================================== --- lib/CodeGen/CodeGenPGO.cpp (revision 201843) +++ lib/CodeGen/CodeGenPGO.cpp (working copy) @@ -199,7 +199,8 @@ llvm::Type *Args[] = { Int8PtrTy, // const char *MangledName Int32Ty,...

I've built chromium with " -fprofile-instr-generate -fsanitize=address" -- the performance looks good! The file format from r198638 is indeed rudimentary. Do you already know how the real output format will look like? Just to summarize what I think is important: - minimal size on disk, minimal amount of files - minimal i/o while writing to disk, no lockf or some such -

...; attribute to cold functions. Indirectly, PGO does affect the >> inliner. (We'll remove this once the inliner does the right thing on >> its own.) > > OT: Can you give me a pointer to the clang code involved? I wasn't aware of > this. It is set in clang/lib/CodeGen/CodeGenPGO.cpp CodeGenPGO::applyFunctionAttributes. Note that it uses the function entry count to determine hotness. This means that functions entered infrequently but containing very hot loops would be marked cold, perhaps this works since it is only used for inlining and is presumably a stand-in for call e...

I’d like to nominate code owners for: PGO (CodeGenPGO, ProfileData, llvm.instprof): Justin Bogner Branch Weights and BlockFrequency: Duncan Smith -Andy

On 05/27/2015 11:13 AM, Duncan P. N. Exon Smith wrote: >> On 2015 May 27, at 07:42, Diego Novillo <dnovillo at google.com> wrote: >> >> On Tue, May 26, 2015 at 11:47 PM, Lee Hunt <leehu at exchange.microsoft.com> wrote: >> >>> For example, from reading different pages on how Clang PGO, it’s unclear if >>> it does “block reordering” (i.e. moving

> On 2015 May 27, at 07:42, Diego Novillo <dnovillo at google.com> wrote: > > On Tue, May 26, 2015 at 11:47 PM, Lee Hunt <leehu at exchange.microsoft.com> wrote: > >> For example, from reading different pages on how Clang PGO, it’s unclear if >> it does “block reordering” (i.e. moving unexecuted code blocks to a distant >> code page, leaving only ‘hot’

...ult.profraw is generated) clang -O2 -fprofile-instr-use=default.profraw test.c -o a.out error: pgo data file has malformed function entry I found that the run-time function "writeFile" in InstrProfilingFile.cpp didn't write '\n'. But when parsing the profile data, in CodeGenPGO.cpp line 56, it tried to find '\n' like below: CurPtr = strchr(CurPtr, '\n'); if (!CurPtr) { ReportBadPGOData(CGM, "pgo data file has malformed function entry"); return; } 2. Problems in autoFDO: Actually the problem happened in using create_llvm_prof...

...om> writes: > Seems fine to me. Not sure if there is part of this that you want to > explicitly call out as owned by Diego. > > On Thu, Dec 11, 2014 at 12:38 AM, Andrew Trick <atrick at apple.com> wrote: > > I’d like to nominate code owners for: > > PGO (CodeGenPGO, ProfileData, llvm.instprof): Justin Bogner > > Branch Weights and BlockFrequency: Duncan Smith > > -Andy > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu >...

Hi guys, I am trying to perform edge profiling using on hello.bc file by using following command opt -insert-edge-profiling hello.bc -o hello-edge.bc but I get the error that option "-insert-edge-profiling" is unknown. Can you please help me to solve the issue. Please note that I am following the paper available at this link http://llvm.org/pubs/2010-12-Preuss-PathProfiling.pdf

...N. Exon Smith <dexonsmith at apple.com>: > It's up to the frontend (or whatever is generating the branch weights > metadata) to scale the branch weights down appropriately. You can have a > look at how clang does it for an example (IIRC, it's in clang's > lib/CodeGen/CodeGenPGO.cpp, but possibly just the caller is there and the > scaling logic is somewhere in LLVM). > > When are your counters overflowing? If they overflow during an > optimization pass, that sounds like a bug. > > > On 2016-Feb-04, at 05:51, Giorgio Zacharo <giorgiozacharo at gmail...

Dear Duncan, Thank you a lot for your feedback. I have a problem though. The branch weights counters overflow in some files and thus I get incorrect numbers. Is there any way to find a workaround for that? Is is supposed to be a known bug or is it something that needs configuration on my part? Again, thank you a lot for your reply. Best Regards, Georgios Zacharopoulos 2016-02-03 18:23

...gh as you would like; what I'm proposing is simply an extension to the existing infrastructure, so it would be enabled automatically as part of code coverage. Mapping of branch regions would be done in CoverageMappingGen and instrumented using the same profiling instrumentation mechanism under CodeGenPGO::mapRegionCounters() and around CodeGenFunction::EmitBranchOnBoolExpr() . In fact, as I mention below, we'd largely be reusing the same profiling counters (except in at least one exception case that I described in my email). The existing functionality of coverage and profiling would still wor...

...knows the difference between a counter for an "if" and a "for" apart implicitly. Just store one set of profiling data and let the frontend sort it out. - Given that, the instrprof libraries needn't know about kinds at all, that can be dealt with locally in clang's CodeGenPGO, where we need to know what to do with the data. I'd just drop the kind completely for now. It'll be easy to add later without affecting much. - We should be able to statically allocate the first entry for each callsite for __llvm_profile_value_data. It will always be there, and fo...

...end-driven instrumentation based profiling used for clang's -fprofile-instr-generate and -fprofile-instr-use currently has logic for handling its data format spread about a few different places: 1. Reading files is done in clang when -fprofile-instr-use is specified. The logic is in CodeGen/CodeGenPGO.cpp. 2. Reading files is done by the (very preliminary) llvm-profdata tool, which does this manually in llvm-profdata.c 3. Writing files is done in compiler-rt, which is invoked by clang's instrumentation when -fprofile-instr-generate is specified. 4. Writing files is done in the llvm-...

...mize the number of insertions. Is that >> algorithm a well-known one or a custom one? Is that described >> somewhere? > > It is a custom approach. I don’t think we have a written description but the code is pretty straightforward. Look at ComputeRegionCounts in clang’s lib/CodeGen/CodeGenPGO.cpp source file. > >> >> On Wed, Mar 25, 2015 at 10:47 PM, Xinliang David Li <davidxl at google.com> wrote: >>> Bob, >>> >>>> Which workload is better? I don’t at all trust users to get this right, at >>>> least for real, non-benchmark...

Can you tell us if you're continuing to use the same approach as described in one of the LLVM meetings, i.e. instrument at the clang AST level? Also, do you generate GCOV files, some yaml, or is this a separate format? And finally in the meeting you had given how you assign counters to the blocks, an algorithm to minimize the number of insertions. Is that algorithm a well-known one or a

> Date: Tue, 14 Apr 2015 21:33:03 -0700 > From: "Duncan P. N. Exon Smith" <dexonsmith at apple.com> > To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> > Subject: [LLVMdev] RFC: Metadata attachments to function definitions > Message-ID: <BF4002F0-06DC-4A25-AF84-7D21AD48121A at apple.com> > Content-Type: text/plain; charset=us-ascii > >

.......profileIndirectCall(); // does both instrumentation >> and profile annotation depending on the context. >> } >> ... >> } >> Organizing the profile data according value profile kind allows profile data to be independently loaded and used: >> .. CodeGenPGO::assignRegionCounters (...) { >> if (enable_indirect_profile) { >> loadValueProfile(VK_indirect_call); >> } >> if (enable_xxx_profile) { >> loadXXXProfile(VK_xxx); >> } >> } >> if we end up with inter-mixing all value kind profile...

...instrumentation > >> and profile annotation depending on the context. > >> } > >> ... > >> } > >> Organizing the profile data according value profile kind allows > >> profile > data to be independently loaded and used: > >> .. CodeGenPGO::assignRegionCounters (...) { > >> if (enable_indirect_profile) { > >> loadValueProfile(VK_indirect_call); > >> } > >> if (enable_xxx_profile) { > >> loadXXXProfile(VK_xxx); > >> } > >> } > >> if we end up...

...ll(...) { if (enable_indirect_profile) { ....profileIndirectCall(); // does both instrumentation and profile annotation depending on the context. } ... } Organizing the profile data according value profile kind allows profile data to be independently loaded and used: .. CodeGenPGO::assignRegionCounters (...) { if (enable_indirect_profile) { loadValueProfile(VK_indirect_call); } if (enable_xxx_profile) { loadXXXProfile(VK_xxx); } } if we end up with inter-mixing all value kind profile data, we will have to load all value profile data into memory regard...