[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gcc
Subject:    Re: RFC: extend cprop_hardreg into a global pass
From:       Steven Bosscher <stevenb.gcc () gmail ! com>
Date:       2012-07-31 15:30:55
Message-ID: CABu31nMA03aM+MW7zm1=MOZ8-z-F1aBktzm3=1DUCqZ0cdQ7hA () mail ! gmail ! com
[Download RAW message or body]

On Tue, Jul 31, 2012 at 4:06 PM, Bin.Cheng <amker.cheng@gmail.com> wrote:
>>
>> For the other PR you mentioned, that looks like a register allocation
>> regression, that should be addresses in IRA rather than in regcprop.
>
> not sure whether this is a RA regression.

Well, it worked before, and now it doesn't. Maybe RA isn't to blame,
but nobody has analyzed the problem (not in the PR audit trail,
anyway) to really understand the problem.


> Though the two pseudo-regs
> are connected by reg-move insn and contains same value afterward,
> the two live ranges(i.e. allocnos) are conflict with each other, thus IRA
> cannot allocate same hard register for them.

If two allocnos have the same value, why can't IRA coalesce them?

And why isn't this overlap copy-propped out before IRA?


> I also measured the effect of extending regcprop.c by sorting basic blocks
> in reverse post-order. Turns out the benefit is very small, because either
> the default order of iteration is nearly reverse post order, or the global
> propagation opportunities are along with loops.

Thanks for trying it. You're right, for loop-carried dependencies a
different iteration order wouldn't make a difference.

Ciao!
Steven
[prev in list] [next in list] [prev in thread] [next in thread]