Jeff Law <l...@redhat.com> writes: > [RFA is for the regcprop bits, reverting the mips.md hack seems like a > no-brainer with the regcprop change. ] > > > Per the recent discussion between Richard S. and myself, this is a > better fix for the mips16 codegen issue where it's creating invalid lwu > insns. > > As Richard S. pointed out there's been a long standing problem where > regcprop would create a reference to the stack pointer that was unique > from stack_pointer_rtx. That's the root cause of the codegen issue. > > We can't re-use stack_pointer_rtx in the code in question because we're > going to modify the underlying RTX in fun and interesting ways. Ports > (such as the mips) assume references to the stack pointer are unique > (ie, they can identify a stack pointer reference by stack_pointer_rtx > rather than checking register #s). > > So this patch just rejects propagation of the stack pointer. It's > conservative in that it doesn't reject other special registers. > > An alternate approach would be to declare that ports can not depend on > looking at stack_pointer_rtx to find all stack references that instead > they have to look at the underlying regno. The amount of auditing here > would be significant. > > I've bootstrapped and regression tested this on x86_64-linux-gnu. It's > also built libgcc/glibc/newlib on about 100 different targets.
Thanks for doing this, looks good to me FWIW. I was wondering whether we should use gen_rtx_REG instead of gen_raw_rtx_REG in maybe_mode_change and then disable the assignment to things like ORIGINAL_REGNO if the returned rtx is one of the global rtxes. But I'm not sure how safe that would be. We don't know whether the original reference to the register number was the global rtx, which might matter for things like hard_frame_pointer_rtx. I think regcprop could be rejigged to handle global rtxes "correctly", but that's obviously too invasive at this stage. Richard
