[llvm-commits] PATCH: Change the strategy for aligning branch targets during MachineBlockPlacement

[Chandler Carruth]

FYI, I finally got back around to this and committed it in r161409. I
implemented the heuristic you suggested of never aligning blocks once they
are cold relative to the function entry, that makes perfect sense.

I've kept the LoopInfo-based logic as I think it's a nice simple way to
reason about what the right strategy is, and we already are using LoopInfo
if we do block placement at all, so we might as well re-use that data....

Let me know if you have any other thoughts on this, I'm happy to keep
tweaking or poking it until its right. Also let me know if you see and perf
regressions that seem likely related.


On Mon, Jul 23, 2012 at 8:34 PM, Andrew Trick <atrick at apple.com> wrote:

> On Jul 16, 2012, at 6:24 AM, Chandler Carruth <chandlerc at gmail.com> wrote:
>
>  Attached is a patch that instead walks the blocks and considers various
> aspects of the layout and the probabilities to decide whether aligning the
> block is likely to be profitable. It uses completely arbitrary heuristics
> which happen to produce results similar to the previous results, but with
> specific fixes to obviously ridiculous alignment such as reported in the PR.
>
> It errs slightly in the direction of aligning fewer branch targets. To my
> mind this is the correct slant because alignment introduces significant
> code bloat and Agners tells me to be very judicious in aligning things as
> it rarely makes a large difference. If anything, I'd like to make this
> *more* conservative, but I'd rather take baby steps.
>
> Does this initial step look good?
>
> Thoughts about how far to go here? I have a follow-up patch that makes the
> whole thing tunable with a commandline flag. I can apply that and run some
> in depth benchmarks, but I suspect that the patch as-is already represents
> a strict improvement over the status quo...
> -Chandler
>
>
> This looks like a good improvement. I'm not used to determining alignment
> without knowing instruction sizes and the actual alignment cost... But your
> approach makes sense.
>
> +    // If the block is cold relative to its loop header, don't align it
> +    // regardless of what edges into the block exist.
>
> What if it's cold relative to its outer loop, or parent function? Cold
> code can have nested loops. If you can get away with frequency relative to
> function entry and layout predecessor, then you don't need LoopInfo here.
>
> -Andy
>
> _______________________________________________
> 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/20120807/7cc3bc83/attachment.html>