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: Richard Biener <richard dot guenther at gmail dot com>
- To: Steven Bosscher <stevenb dot gcc at gmail dot com>, Jeff Law <law at redhat dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, "Vladimir N. Makarov" <vmakarov at redhat dot com>
- Date: Fri, 19 Apr 2013 10:21:38 +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> <20130418230811 dot GB3859 at alvy dot suse dot cz>
On Fri, Apr 19, 2013 at 1:08 AM, Martin Jambor <firstname.lastname@example.org> wrote:
> 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
>> * 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? ;-)
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 a lot,