[PATCH, PR 10474] Shedule pass_cprop_hardreg before pass_thread_prologue_and_epilogue

[Richard Biener]

On Fri, Apr 19, 2013 at 1:08 AM, Martin Jambor <mjambor@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?

Thanks,
Richard.

> Thanks a lot,
>
> Martin
>