This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH, PR 10474] Shedule pass_cprop_hardreg before pass_thread_prologue_and_epilogue
- From: Martin Jambor <mjambor at suse dot cz>
- To: Steven Bosscher <stevenb dot gcc at gmail dot com>
- Cc: Jeff Law <law at redhat dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 19 Apr 2013 01:08:11 +0200
- Subject: Re: [PATCH, PR 10474] Shedule pass_cprop_hardreg before pass_thread_prologue_and_epilogue
- References: <20130417154935 dot GC3656 at virgil dot suse> <516EED6F dot 9030007 at redhat dot com> <20130418220949 dot GA3859 at alvy dot suse dot cz> <CABu31nOXYxWNHmSCbcQ=at8QrAHO1ABXROk6dLaq4iVuYv8MLQ at mail dot gmail dot com>
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
> 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
> * 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
> 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? ;-)
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.
Thanks a lot,