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: Steven Bosscher <stevenb dot gcc at gmail dot com>
- To: Jeff Law <law at redhat dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 19 Apr 2013 00:37:58 +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>
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
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
* 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.