On 04/18/2013 05:08 PM, Martin Jambor 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.
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.
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.
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?
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.
First, where can I have a look how a live range is split? ;-)
There's been several implementations through the years; none that I'd
say is suitable for reuse.
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,
Martin
