Displaying 4 results from an estimated 4 matches for "calcmetadataweight".
Did you mean:
calcmetadataweights
2015 Apr 24
2
[LLVMdev] Loss of precision with very large branch weights
...9;t really need 64bits, as they're just
> comparative values that can be squished into 32bits. It's the branch
> weights being 32 bit quantities that are throwing off the calculations.
Do you still see the issue after fixing bhe bug (limit without scaling) in
BranchProbabilityInfo::calcMetadataWeights ?
David
>
>
> Diego.
2015 Apr 24
3
[LLVMdev] Loss of precision with very large branch weights
yes -- for count representation, 64 bit is needed. The branch weight
here is different and does not needs to be 64bit to represent branch
probability precisely.
David
On Fri, Apr 24, 2015 at 12:21 PM, Smith, Kevin B
<kevin.b.smith at intel.com> wrote:
> FWIW. Intel compiler's profile instrumentation uses 64 bit integer counters.
> We wrestled with similar problems for a long
2015 Mar 24
3
[LLVMdev] RFC - Improvements to PGO profile support
...seen any consensus on this. I’m not at all convinced this would be a good idea. From what I’ve seen, using LaPlace’s rule avoids really bad behavior in cases where the counts are very small and has almost no impact when the counts are large.
> 2.4) Fix the bug in 'BranchProbabilityInfo::calcMetadataWeights'
> that does capping without scaling
> 2.5) Fix a similar bug in 'MachineBranchProbabilityInfo::getSumForBlock('
> .. other bugs found
> 3) introduce a new meta data to represent function entry global
> hotness (the implementation can choose to use entry execution c...
2015 Mar 24
8
[LLVMdev] RFC - Improvements to PGO profile support
On 03/10/2015 10:14 AM, Diego Novillo wrote:
>
>
> On Thu, Mar 5, 2015 at 11:29 AM, Bob Wilson <bob.wilson at apple.com
> <mailto:bob.wilson at apple.com>> wrote:
>
>
>> On Mar 2, 2015, at 4:19 PM, Diego Novillo <dnovillo at google.com
>> <mailto:dnovillo at google.com>> wrote:
>>
>> On Thu, Feb 26, 2015 at 6:54 PM,