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

Chandler Carruth via llvm-commits llvm-commits at lists.llvm.org
Wed Jan 25 17:33:40 PST 2017


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:

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.

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.

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


More information about the llvm-commits mailing list