[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

[Alastair Murray]

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.