On Fri, Jan 16, 2015 at 08:09:51PM -0600, Segher Boessenkool wrote: > On Sat, Jan 17, 2015 at 11:07:12AM +1030, Alan Modra wrote: > > On Fri, Jan 16, 2015 at 11:03:24AM -0600, Segher Boessenkool wrote: > > > On Fri, Jan 16, 2015 at 08:12:27PM +1030, Alan Modra wrote: > > > > OK, so we need to fix this in the rs6000 backend, but it occurs to me > > > > that cprop also has a bug here. It shouldn't be touching fixed hard > > > > registers. > > > > > > Why not? It cannot allocate a fixed reg to a pseudo, but other than > > > that there is nothing special about fixed regs; the transform is > > > perfectly valid as far as I see. > > > > I didn't say that copying to a pseudo and using that was invalid.. > > The bug I see is a mis-optimisation. > > Ah, okay, good :-) > > This same mis-optimisation would happen if r1 was just some regular > non-fixed register, hrm. Maybe something else in cprop needs some > tuning up?
Well, if the original pseudo register dies earlier as a result of substituting a copy then you've gained. > > Also, the asm operands case that > > do_local_cprop already rules out changing is very similar to fixed > > regs. Would you argue that changing asm operands is also valid? :) > > A fixed reg in an asm_operands is a hard reg; a hard reg in an asm_operands > (before reload) is a register asm variable. And we had better not change > register variable asm arguments, since that is what we promise not to do > with register variables. The case is not similar at all. The similarity I see is that we have a hard reg that is a register asm variable here too. How else do you get a copy from a fixed hard reg to a pseudo? Hrrm, maybe some backend code does that sort of thing. > > > It isn't a desirable transform in this case, but that is not true for > > > fixed regs in general (just because the stack pointer is live everywhere). > > > > What's the point in extending the lifetime of some pseudo when you > > know the original fixed register is available everywhere? > > That is my point: _if_ you know it is live all the time, or if there is no > advantage to shortening the lifetime of the value in that fixed reg, then > yes we should not propagate that value. But that is not true for all > fixed regs. > > > Do you have > > some concrete example in mind where this "optimisation" is beneficial? > > The CA_REG in rs6000 is a fixed register. It isn't a terribly good > example because it cannot be propagated anyway, for other reasons; but > it will hopefully help explain my point. So please pretend we can copy > it to GPRs :-) [ The situation with the T bit on SH is similar, but I > don't know the details there well enough. ] > > There is only one CA_REG. It is used in quite a few sequences. It > contains a totally different value every time. Because there is only > one such register the instruction sequences around it cannot be reordered > very well. > > Propagating the value in such a not-so-very-fixed fixed reg helps reduce > the lifetimes of the values in those regs, helps reordering, combining, > scheduling, performance in general. > > If you are only concerned about the stack pointer, you could just check > for that? But please add a comment in any case, saying why you exclude > it (and ideally don't lump it in with tests that are needed for > correctness). No, I don't want to special-case sp. That's horrible. If the patch I just committed is wrong, I'll revert it. -- Alan Modra Australia Development Lab, IBM