This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA][PATCH] Fix mips16 codegen issue in a better way


On 04/18/2017 05:16 AM, Richard Sandiford wrote:
Jeff Law <law@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'd also be concerned that not setting something like REG_POINTER or REG_ATTRS could cause problems.

While I can probably get to "safe" for current intersection ports, special registers and how they interact with REG_POINTER, it feels rather fragile.

Jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]