[llvm-commits] [llvm] r162799 - in /llvm/trunk: include/llvm/Analysis/Passes.h include/llvm/Analysis/ProfileDataLoader.h include/llvm/InitializePasses.h include/llvm/LinkAllPasses.h lib/Analysis/Analysis.cpp lib/Analysis/CMakeLists.txt lib/Analysis/ProfileDataLoader.cpp lib/Analysis/ProfileDataLoaderPass.cpp lib/Analysis/ProfileInfo.cpp test/Analysis/Profiling/load-branch-weights-ifs.ll test/Analysis/Profiling/load-branch-weights-loops.ll test/Analysis/Profiling/load-branch-weights-switches.ll

Bob Wilson bob.wilson at apple.com
Sat Sep 1 21:56:52 PDT 2012


It seems like it would be better to scale all the values, rather than saturating.  The relative execution frequencies are what matter for this and you'll lose that by saturating.

On Sep 1, 2012, at 9:17 AM, Alastair Murray <alastairmurray42 at gmail.com> wrote:

> Hi Bill,
> 
> On 31/08/12 01:21, Bill Wendling wrote:
>> On Aug 30, 2012, at 4:23 PM, Alastair Murray <alastairmurray42 at gmail.com> wrote:
> > Yes, I could do this.  Reading between the lines, however, I could
> > just not saturate on overflow but leave it unhandled?  Is that
> > preferable?
> 
>> On 30/08/12 21:24, Bill Wendling wrote:
>> If you could give an example of what you're trying to do, that might be better. We may not be talking about the same thing. What does the math look like that you're trying to handle by going to uint64_t?
> 
> The main issue is that profiling data can be generated over multiple program run, the data being concatenated on the end of the profiling dump file for each run.
> 
> When this are loaded the multiple runs are reduced to a single set of data (via addition).
> 
> So if run 1 sets a counter to 4 billion, and run 2 set the same counter to 3 million then adding these together exceeds UINT32_MAX.  So the idea is to saturate to UINT32_MAX-1 (UINT32_MAX is used to represent Uncounted).
> 
> The alternative is to ignore this and just overflow (so the counter becomes 4.3 billion - UINT32_MAX).  If the counter overflows within single run of a program (say a function is called 5 billion times) then this is what happens.
> 
> Perhaps APInt should be used within ProfileDataLoader* instead, that would allow doing all arithmetic in, say, 64-bits and just saturating to UINT32_MAX when writing out the branch weight metadata.
> 
> Regards,
> Alastair.
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits




More information about the llvm-commits mailing list