[LLVMdev] Separating loop nests based on profile information?

[Xinliang David Li]

On Mon, Jan 19, 2015 at 5:43 PM, Philip Reames <listmail at philipreames.com>
wrote:

>
> On 01/12/2015 07:39 PM, Xinliang David Li wrote:
>
>
>
> On Wed, Jan 7, 2015 at 5:33 PM, Chandler Carruth <chandlerc at google.com>
> wrote:
>
>>
>>
>> How does this compare with classical approaches of loop peeling,
>> partitioning, fission, or whatever you might call it? Is there any
>> literature behind this approach or some literature it should be compared
>> with? (I genuinely don't know this area that well, so I'm of little help
>> here...)
>>
>
>
>  It is not any of those loop transformations. It does not even change the
> control flow. It is more a code layout optimization -- move the cold trace
> in the loop out of the body.
>
> It's also a somewhat major change in the canonical form of the loop as
> seen by the optimizer.  That's probably the more important part in
> practice.
>

right.

>
>
>
>>>    - If so, is the notion of 'rareness' of a loop block something
>>>    that's worth extracting out on it's own and reusing? Are there other
>>>    similar uses anyone can think of?
>>>    - Currently, I'm only supporting a fairly small set of controlling
>>>    conditions. Are there important cases I'm not considering?
>>>
>>>    To both of these, I think the general combination to use is to
>> identify the set of blocks dominated by a block which is in the loop body
>> of a hot loop, and is cold relative to the other successors of its
>> predecessor(s). These form cold "regions" as I think of them without
>> requiring the complexity of the region analysis.
>>
>>
>
>  Static prediction should handle it  --  call heuristics or some
> combination with other heuristics (error handler recognition etc).
>
>    Sorry, I'm really not sure what you're trying to say here.  Could you
> clarify/expand?
>

It is more of a comment about identify rare blocks -- there are cases where
static heuristics can produce branch prediction with high confidence.

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150119/ad77821b/attachment.html>