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

[Xinliang David Li via llvm-commits]

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.

>
> 1) Principle of least surprise when debugging, performance analyzing, etc.
> It is very useful if boring C-like code remains in the same basic structure
> it came in as when the compiler has no good reason to reorder it.
>

For optimized build, debuggability should not be the guiding principle.  On
the the hand, I can see the usefulness of  option such as -Og  (or even
source level directives) which turns on useful optimization but also tries
to preserve debuggability of the program.


>
> 2) Reduce surprising churn of order. Basic source code edits that don't
> re-arrange the order of code shouldn't rearrange the order of generated
> code. Otherwise, innocuous changes trigger performance regressions that
> aren't interesting -- the old version got lucky and the new version gets
> unlucky. There isn't anything to do, but users dislike the surprising noise
> in their benchmarks.
>

This is not necessarily true already. If a branch code condition is
changed, it will likely trigger branch prediction to produce very different
result.


>
> 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.

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

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/20170125/a95b8c67/attachment.html>