Diego Novillo
2015-Apr-24 18:36 UTC
[LLVMdev] Loss of precision with very large branch weights
On Fri, Apr 24, 2015 at 2:32 PM, Xinliang David Li <davidxl at google.com> wrote:> Since we have decided to capture the global hotness using function > entry count, it is ok to CAP the max weight as of today. I think the > remaining bug in PR22718 is that when capping happens, the scaling is > not done. That needs to be fixed. >The problem here is that the two loops show up equally hot. So the function entry count for bar() won't really help since it seems like both loops call bar() equally frequently.> The efficiency of the interface is a different issue. > >Yeah. I'm looking at the hotness calculation first. Diego. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150424/a44ad583/attachment.html>
Xinliang David Li
2015-Apr-24 18:44 UTC
[LLVMdev] Loss of precision with very large branch weights
On Fri, Apr 24, 2015 at 11:36 AM, Diego Novillo <dnovillo at google.com> wrote:> > > On Fri, Apr 24, 2015 at 2:32 PM, Xinliang David Li <davidxl at google.com> > wrote: >> >> Since we have decided to capture the global hotness using function >> entry count, it is ok to CAP the max weight as of today. I think the >> remaining bug in PR22718 is that when capping happens, the scaling is >> not done. That needs to be fixed. > > > The problem here is that the two loops show up equally hot. So the function > entry count for bar() won't really help since it seems like both loops call > bar() equally frequently. >Isn't that the direct result of the branch weights not being scaled (after reaching the cap) -- thus leading to wrong branch probability (computed from weights)? Wrong probability leads to wrong Frequency propagation. David>> >> The efficiency of the interface is a different issue. >> > > Yeah. I'm looking at the hotness calculation first. > > > Diego.
Diego Novillo
2015-Apr-24 18:46 UTC
[LLVMdev] Loss of precision with very large branch weights
On 04/24/15 14:44, Xinliang David Li wrote:> > Isn't that the direct result of the branch weights not being scaled > (after reaching the cap) -- thus leading to wrong branch probability > (computed from weights)? Wrong probability leads to wrong Frequency > propagation.Yup, I'm trying to see if we couldn't just use 64bit values all over to make things easier. The drawback would be that we are just punting the problem to a different scale of values (but, it may be enough). Diego.
Seemingly Similar Threads
- [LLVMdev] Loss of precision with very large branch weights
- [LLVMdev] Loss of precision with very large branch weights
- [LLVMdev] Loss of precision with very large branch weights
- [LLVMdev] Loss of precision with very large branch weights
- [LLVMdev] fix for loop scale limiting in BFI