[PATCH] D28583: CodeGen: Allow small copyable blocks to "break" the CFG.
Andrew Trick via llvm-commits
llvm-commits at lists.llvm.org
Thu Jan 26 11:30:50 PST 2017
> On Jan 25, 2017, at 5:33 PM, Chandler Carruth via llvm-commits <llvm-commits at lists.llvm.org> wrote:
>
> Just to explicitly chime in here...
>
> On Wed, Jan 25, 2017 at 4:32 PM Kyle Butt <iteratee at google.com <mailto: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.
It makes sense to me. That’s an accurate synopsis. Completely arbitrary code relayout in the absence of PGO or static heuristics is an annoying thing for the compiler to do. That said, I have no idea what’s at stake with the successor order—being deterministic is usually good enough.
-Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170126/78f325c8/attachment.html>
More information about the llvm-commits
mailing list