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

Eric Christopher echristo at gmail.com
Tue Feb 4 18:55:18 PST 2014


On Tue, Feb 4, 2014 at 4:31 PM, Chandler Carruth <chandlerc at google.com> wrote:
> 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.
>

This is definitely the important case here since our default "we don't
know" is going to be a 50/50 probability where everything is equally
likely, not less likely because of conditionals.

-eric



More information about the llvm-dev mailing list