<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Jul 28, 2015 at 3:58 PM Cong Hou <<a href="mailto:congh@google.com">congh@google.com</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I found it not straightforward to normalize weights in MBPI. Note that MBPI reads weights from MBB, which provides the interface addSuccessor(MachineBasicBlock *succ, uint32_t weight) to let users indicate arbitrary weights for new added edges. Because we don't know how users use this interface, it can be difficult to adjust weights in MBB. I think there may be two solutions:<br>
<br>
1. We provide the interface normalizeWeights in MBB. Once we call this interface, the sum of weights is guaranteed to be less than UINT32_MAX. However, after the user add new successors with weights, we need to re-normalize it. This can still be useful when we want to calculate branch probabilities or do other adjustment after the weights are normalized.<br>
<br>
2. We maintained both normalized and original weights in MBB, so that once the original weights is modified, we also adjust the normalized weights. This solutions requires more space and more frequent calculations comparing to the first one, but the normalized weights are always guaranteed.<br>
<br>
Do you have any other ideas? Or which one do you think is better?<br></blockquote><div><br></div><div>First off, yuck, but thanks for digging into this.</div><div><br></div><div>3. Another alternative might be to keep the sum stored, and when adding a weight, we could simply check if that would overflow, if so, re-normalize everything. It would require auditing code that adds a successor to ensure it doesn't rely on the weights after adding a successor being the same, but that seems unlikely to come up.</div><div><br></div><div>I'd particularly like to hear Duncan's thoughts on which of these options would make most sense. I see pros and cons on all of these. I think I'd be fine with either #1 or #3. I agree with your concern over the space requirements of #2.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
<a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_D10825&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=mQ4LZ2PUj9hpadE3cDHZnIdEwhEBrbAstXeMaFoB9tg&m=3ZAH58kOM8pB46vtp66JTeR4Xln8s2u4mjggIu41Qew&s=0fOAGqVEKjk49dx8A_SCNEm65_R6Z54NoA-YE1uKFZM&e=" rel="noreferrer" target="_blank">http://reviews.llvm.org/D10825</a><br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
</blockquote></div></div>