On Tue, Jul 31, 2012 at 4:06 PM, Bin.Cheng <amker.ch...@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
