On 03/08/15 09:35, Richard Biener wrote:
On March 8, 2015 3:39:08 PM CET, Ajit Kumar Agarwal
<ajit.kumar.agar...@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
