This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]