The current integer representation of relative block frequency prevents
representing relative block frequencies below 1. This change uses a 8 of
the 29 bits to represent the decimal part by using a fixed scale of -8.
Details
Diff Detail
- Repository
- rL LLVM
- Build Status
Buildable 15207 Build 15207: arc lint + arc unit
Event Timeline
include/llvm/IR/ModuleSummaryIndex.h | ||
---|---|---|
63 | Documented. Yes, users should scale it back. In a separate patch, I will add a method to get this value as a ScaledNumber or uint64_t so that the users don't have to explicitly scale them | |
65 | No, this is just the max value of the digits in the 29 bit bit-field. | |
86 | Somehow missed this in refactoring. |
include/llvm/IR/ModuleSummaryIndex.h | ||
---|---|---|
65 | then the 'min' function here Sum = std::min(Sum, uint64_t(MaxRelBlockFreq)); should use a scaled MaxRelBlockFreq, right? |
include/llvm/IR/ModuleSummaryIndex.h | ||
---|---|---|
65 | No. The intent is to use a max of 29 bits including the integer and decimal(fractional) bits. Since I use a scale of 8, 8 bits will be used to represent values below 1 and I can use only 21 bits to represent the integral part. |
Document that it is RelativeBlockFrequency scaled by 2^8
Also should all the uses of RelBlockFreq scale it back?