[PATCH] D28583: CodeGen: Allow small copyable blocks to "break" the CFG.

[Eric Christopher via llvm-commits]

On Wed, Jan 25, 2017 at 6:18 PM Xinliang David Li <davidxl at google.com>
wrote:

> On Wed, Jan 25, 2017 at 5:33 PM, Chandler Carruth <chandlerc at gmail.com>
> wrote:
>
> Just to explicitly chime in here...
>
> On Wed, Jan 25, 2017 at 4:32 PM Kyle Butt <iteratee at google.com> wrote:
>
> Why is it important to track that ?
>
>
> Chandler can back me up here, but front ends and users rely on source
> order of branches being a slight hint in the absence of other evidence.
> Going through in a second pass the only way to preserve that is to somehow
> record the order of the first pass. Stable sort just doesn't keep enough
> information.
>
>
> The idea when Andy and I started the original discussion around MBP was as
> follows:
>
> In some cases we won't have good profile signals or good CFG structure
> signals. In those cases, we should preserve source order of code for three
> reasons in decreasing order of importance:
>
>
> Static prediction heuristics use many different signals, but I am not
> aware of any using source locations. If there is such heuristic which
> proves to be useful, it
>
> 1) should be considered in branch probablity analysis
> 2) use the actual debug source location instead of CFG iterator order as
> used in Kyle's code.
>

FWIW Andy and I noticed this when doing scheduling work as well. Basically
use the source ordering as a tie breaker in cases where each branch is
equally profitable.



> 3) If a benchmark has source order that leads to faster code layout than
> some other order, the compiler shouldn't break that in the case where it
> has no good information.
>
>
> User can always annotate branches with __builtin_expect to give compiler
> hint. It is not reasonable for the optimizing compiler to assume user has
> made the the best possible decisions -- which often in times are wrong.
>
>
Agreed, but I'm not a huge fan of annotating branches.


> For instance, compiler can undo user's unroll with loop re-rolling, undo
> users inlining with function outlinining etc.
>

It can, but take something like the hot hand unrolled loop from something
like John the Ripper here - basically the user already scheduled the code
to maximize ILP for the function, if we choose source order for our tie
break then we can keep the tuning that the user gave.

I'm not saying that this is the best method to determine any of this, just
giving a bit more background as to what we were thinking at the time.

-eric


>
> David
>
>
> I think this was more important before we had good PGO, but I think it
> remains mildly useful. In some ways, its just an extension of #2.
>
> Hope this makes sense.
>
> -Chandler
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170126/b28fdd9c/attachment.html>