[PATCH] Add a flag to experiment with outlining optional branches.

[Xinliang David Li]

Daniel,

your patch strongly is strongly in favor of outlining even when edge A->C
is not the best successor edge in terms of branch probability -- note the
condition SuccProb > HotProb.getCompl() which is 20% if I read it correctly.

Outlining aggressively has the side effect of 1) increasing code size (due
to the unconditional branch, possibly long branch) and 2) increases the
number of taken branches dynamically.

In fact, the tuning can be done by simply adjusting the HotProb value -- as
this control flow pattern should be covered (as one of the cases) in the
following code:

if (SuccChain.LoopPredecessor != 0) {
 ...
}

You probably don't need to compute postDom either -- the CFG shape can be
easilly checked by peeking at the predecessor/successor blocks.

thanks,

David


On Wed, Feb 18, 2015 at 1:47 AM, Daniel Jasper <djasper at google.com> wrote:

> Hi chandlerc,
>
> In a CFG with the edges A->B->C and A->C, B is an optional branch.
>
> LLVM's default behavior is to lay the blocks out naturally, i.e. A, B, C,
> in order to improve code locality and fall throughs. However, if a function
> contains many of those optional branches only a few of which are taken,
> this leads to a lot of unnecessary icache misses. Moving B out of line can
> work around this.
>
> http://reviews.llvm.org/D7719
>
> Files:
>   lib/CodeGen/MachineBlockPlacement.cpp
>   test/CodeGen/X86/code_placement_outline_optional_branches.ll
>
> EMAIL PREFERENCES
>   http://reviews.llvm.org/settings/panel/emailpreferences/
>
> _______________________________________________
> 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/20150218/84d1ceb5/attachment.html>