Re: Proposal for path splitting for reduction in register pressure for Loops.

[Jeff Law <law at redhat dot com>]

On 03/08/15 09:35, Richard Biener wrote:
> On March 8, 2015 3:39:08 PM CET, Ajit Kumar Agarwal <ajit.kumar.agarwal@xilinx.com> wrote:
> > Hello All:
> >
> > The path splitting that replicates the code for better Data flow
> > Analysis available. One of the properties
> > of path splitting removes the joining nodes for the forked path like
> > IF-THEN-ELSE and the Loops.
> >
> > The removal of joining nodes makes the path splitted into two
> > independent paths.
> >
> > The increase in register Pressures for the loops are the performance
> > bottleneck and sometimes
> > lead to spill code in loops.
> >
> > The removal of joining nodes like loops and IF-THEN-ELSE makes the
> > target independent optimization like
> > CSE and Partial redundancy Elimination effective. Along with ease of
> > these optimization the path splitting
> > reduces the registers because Of the Liveness wont intersect because of
> > independent splitted path. The
> > ease of less intersection of liveness Reduces the register pressure for
> > the Loops, thus better register
> > allocation and less spilling code for Loops.
> >
> > The heuristics used in IRA code for register pressure will have better
> > impact on the splitted path and thus
> > optimized code.
> >
> > Thoughts Please?
>
> Are you talking about loop unswitching?
It's more like superblock formation.  You duplicate from the join point 
into the predecessors.  The actual transformation is very similar to 
what we do for join blocks in jump threading paths, though we do it in 
two steps (first we duplicate the entire join point, then let later 
passes merge that into the predecessor if it's profitable to do so)

I'm not sure how much a more generalized path splitter buys us -- PRE 
picks up a lot of the redundancies that were traditionally exposed by 
superblock formation.   And jump threading picks up the branching 
redundancies that tend to get exposed.

I've pondered from time to time using jump threader to guide this kind 
of transformation -- it actually has enough knowledge to say "hey,
instructions I1, I3, I5 in this this block are actually redundant when 
the block is reached via path P".  But I've never bothered to implement. 
 It also doesn't fit well into the long term plans to change the 
threader from a forward walk to a backward walk.

LLVM has integrated a very limited form of this transformation into 
their jump threader, specifically for memory loads.
Jeff