RFC: extend cprop_hardreg into a global pass

[Steven Bosscher]

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