[LLVMdev] [RFC] BlockFrequency is the wrong metric; we need a new one

[Chandler Carruth]

Will respond in more detail to the other points, but just to isolate this
one briefly:

On Tue, Feb 4, 2014 at 4:07 PM, Duncan P. N. Exon Smith <
dexonsmith at apple.com> wrote:

> > Regarding (1). You've probably already considered any impact on block
> layout, so I'll ignore that. For code motion/placement, I'm also not sure
> about your method of "scaling upward" within acyclic control flow. I'm used
> to thinking that if a block has higher weight it must be more frequently
> executed. So if I place code on the lightest block, I am either (a)
> hoisting it outside a loop or (b) sinking it below branches or above merges.
>
> I also think block frequency is more useful for (1).


I actually think they are both equivalent. We only really use them to scale
an edge probability prior to comparing two edge probabilities from
different source basic blocks, and to form a total ordering over the basic
blocks when we've completely given up on laying out code according to any
part of the CFG.

The latter case doesn't matter much -- source order is probably just as
good of a fallback. At this point, we've lost all real hope of doing "good"
code layout.

The former case is interesting, but if anything I think would do better
with the new approach: we won't consider one edge "cold" and thus OK to
break out of the CFG natural ordering (or out of the loop nest) merely
because it happens to have 5 50/50 branches predicating it and the other
block has only 1. That case doesn't seem likely to come up often, but if it
did come up, I would prefer the logic of using weights at the relative
scale for the edges.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140204/5bb1bdc8/attachment.html>