On 13-04-19 4:21 AM, Richard Biener wrote:
On Fri, Apr 19, 2013 at 1:08 AM, Martin Jambor <mjam...@suse.cz> wrote:
Hi,
On Fri, Apr 19, 2013 at 12:37:58AM +0200, Steven Bosscher wrote:
On Fri, Apr 19, 2013 at 12:09 AM, Martin Jambor wrote:
I also have not tried scheduling the hard register copy propagation
pass twice and measuring the impact on compile times. Any suggestion
what might be a good testcase for that?
I think a better question is when this would be useful in the first
place, and why. In other words: If you propagate hardregs before
shrink wrapping, what could be a source of new opportunities after
shrink wrapping?
Yes, we also did that and neither I nor Honza could think of any
potential problems there. And of course, I'd also measure how many
statements the second run of the pass changed. I'll probably do that
tomorrow anyway.
The only things I can think of, given the current pass order, are:
* different basic block order due to shrink wrapping
regcprop's effectiveness depends on the order of the basic blocks
(unfortunately)
* different basic block contents due to head/tail merging (pass_jump2)
Head/tail merging extends some basic blocks and shortens others. The
elongated basic blocks may present new opportunities (regcprop is a
local pass).
* different basic block contents due to dead store elimination (pass_dse2)
A removed dead store may also make an address calculation redundant,
changing the regcprop value chains.
* different basic block contents due to peephole2
A peephole2 may present new regcprop opportunities, peephole2 misses
the context to avoid trivial copies.
On the other hand, running regcprop earlier also helps some other
passes. For example, I think regcprop before jump2 may result in more
successful head/tail merging attempts by making more input operands
match, but it could hurt if_after_reload by extending live times of
registers.
But wouldn't it be better to avoid these argument-register pseudos
being assigned to callee-saved registers? Perhaps splitting the live
range of the pseudos before the first call on each path will do the
trick, and let IRA pick the right registers for you instead.
First, where can I have a look how a live range is split? ;-)
Insert a copy and adjust all dominated uses:
(set (new-pseudo old-pseudo))
... adjust downstream uses of old-pseudo to use new-pseudo ...
But second, if such a call is in a loop (or accessible by more than
one path), I wouldn't it be wrong to do that? To avoid that, I
suppose I might end up doing another shrink-wrapping-like search for
the right edge for prologue and actually coming up with a very similar
result to the propagation and shrink-wrapping preparation. But I'm
willing to try.
I suppose splitting life-ranges in general before argument setup might
make sense - I see hardreg copyprop as a hack around limitations
in register allocation. Note that life-range splitting is undone by
regular copy propagation.
ISTR IRA splits life-ranges in loop code, so there must be already
some helpers that could be used. Vlad?
I'd not recommend to reuse this code as actual live-range splitting
is buried under a lot of code to modify IR of IRA as we need the IR
after live-range splitting. Long ago I used splitting and rebuilding IR
but building IR is a very time consuming procedure (I guess 1/2 of IRA)
therefore the current solution is used.
There is an alternative simpler code for this in IRA. The code was
written by Bernd:
http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01531.html
By the way, I have plans to do a separate register pressure
decreasing pass based on live-range shrinkage and rematerialization. I
found that we need this as more optimizations have a tendency to deal
with this issue by themselves. May be I'll find time to do this in this
year (but most probably not for gcc4.9). I am not sure even for release
next after gcc4.9.
