[LLVMdev] Separating loop nests based on profile information?

Philip Reames listmail at philipreames.com
Mon Jan 19 17:43:28 PST 2015


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 
> <mailto: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.
>
>
>           * 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150119/fe849543/attachment.html>


More information about the llvm-dev mailing list