[PATCH] D10825: Improvement on computing edge probabilities when choosing the best successor in machine block placement.

[Chandler Carruth]

On Tue, Jul 28, 2015 at 3:58 PM Cong Hou <congh at google.com> wrote:

> 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:
>
> 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.
>
> 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.
>
> Do you have any other ideas? Or which one do you think is better?
>

First off, yuck, but thanks for digging into this.

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.

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.


>
>
> http://reviews.llvm.org/D10825
>
>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150728/7b438122/attachment.html>