Displaying 6 results from an estimated 6 matches for "blockfreq".
2009 Jul 14
0
[LLVMdev] Profiling in LLVM Patch Followup 1
...this class, and moved the main printing functionality to its
run method. This avoids the member state.
> class ProfileAnnotator : public AssemblyAnnotationWriter {
> - std::map<const Function *, unsigned> &FuncFreqs;
> - std::map<const BasicBlock*, unsigned> &BlockFreqs;
> - std::map<ProfileInfoLoader::Edge, unsigned> &EdgeFreqs;
> + ProfileInfo *PI;
I would advocate making this a reference instead of a pointer; that
makes it obvious that this class doesn't own the ProfileInfo, and that
the client is responsible for its memory managemen...
2009 Jul 02
1
[LLVMdev] Profiling in LLVM Patch Followup 1
Hi,
this is the first in a series of patches to cleanup and improve the LLVM Profiling Infrastructure.
First and foremost this patch removes duplicate functionality from ProfileInfoLoader and ProfileInfo:
The ProfileInfoLoader performed not only the loading of the profile information but also some synthesis of block and function execution counts from edge profiling information. Since the
2009 Jul 22
4
[LLVMdev] Profiling in LLVM Patch Followup 1
...the main printing functionality to its
> run method. This avoids the member state.
>
>> class ProfileAnnotator : public AssemblyAnnotationWriter {
>> - std::map<const Function *, unsigned> &FuncFreqs;
>> - std::map<const BasicBlock*, unsigned> &BlockFreqs;
>> - std::map<ProfileInfoLoader::Edge, unsigned> &EdgeFreqs;
>> + ProfileInfo *PI;
>
> I would advocate making this a reference instead of a pointer; that
> makes it obvious that this class doesn't own the ProfileInfo, and that
> the client is responsi...
2014 Mar 07
2
[LLVMdev] [RFC] BlockFrequency is the wrong metric; we need a new one
...These merely express the likelihood of taking one of a mutually exclusive set of exit paths from a basic block. They are very simple, and the foundation of the profile information. Even the other analysis is merely built on top of this one.
>>>>>
>>>>> Second we have BlockFrequencyInfo which attempts to provide a more "global" (function-wide, not actually program wide) view of the statistical frequency with which any particular basic block is executed. This is nicely principled analysis that just computes the probabilistic flow of control through the various br...
2009 Jul 01
12
[LLVMdev] Profiling in LLVM Patch
Hi Daniel,
Daniel Dunbar wrote:
> Hi Andreas,
>
> First, thanks again for undertaking this work and submitting it back. There is a
> lot of good stuff here and it would be great to see it get back into the tree.
Thanks for taking the time to review this, I know its a huge patch. I still have a few questions on how you would like this patch to be re-factored and split up.
> [...]
2014 Feb 05
4
[LLVMdev] [RFC] BlockFrequency is the wrong metric; we need a new one
...probabilities. These merely express the likelihood of taking one of a mutually exclusive set of exit paths from a basic block. They are very simple, and the foundation of the profile information. Even the other analysis is merely built on top of this one.
>> >
>> > Second we have BlockFrequencyInfo which attempts to provide a more "global" (function-wide, not actually program wide) view of the statistical frequency with which any particular basic block is executed. This is nicely principled analysis that just computes the probabilistic flow of control through the various br...