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: Jeff Law <law at redhat dot com>
- To: Steven Bosscher <stevenb dot gcc at gmail dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 19 Apr 2013 09:27:28 -0600
- 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> <20130418230811 dot GB3859 at alvy dot suse dot cz>
On 04/18/2013 05:08 PM, Martin Jambor wrote:
I'd be very curious to see those numbers. While I tend to think the
opportunities missed by just running it early will be in the noise and
nothing we can or should do anything about given the compile-time cost
of running it twice. However, experience has shown it's worth doing the
investigative work to be sure.
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
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
Isn't one of the difficulties here that the pseudo might correspond to
an argument that wasn't passed in a register? Thus you need alias
analysis to know if it's valid to sink the load?
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.
At least that's one of the issues I recall when I looked at this a
couple years ago.
If we constrain ourselves to just sinking argreg->pseudo copies then we
can obviously avoid that problem.
Rather than necessarily looking at this as a range splitting problem,
can it be looked as a sinking problem? Ultimately what we want is to
sink those annoying arg->pseudo setups. It seems like it'd be a fairly
simple dataflow problem to determine those points.
There's been several implementations through the years; none that I'd
say is suitable for reuse.
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,