This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][MIPS] Fix register renaming in the interrupt handlers
- From: Mike Stump <mikestump at comcast dot net>
- To: Richard Sandiford <rdsandiford at googlemail dot com>
- Cc: Robert Suchanek <Robert dot Suchanek at imgtec dot com>, "Catherine_Moore at mentor dot com" <Catherine_Moore at mentor dot com>, Matthew Fortune <Matthew dot Fortune at imgtec dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 13 Aug 2015 15:14:40 -0700
- Subject: Re: [PATCH][MIPS] Fix register renaming in the interrupt handlers
- Authentication-results: sourceware.org; auth=none
- References: <B5E67142681B53468FAF6B7C31356562441B01AD at hhmail02 dot hh dot imgtec dot org> <87k2szc6b9 dot fsf at googlemail dot com>
On Aug 13, 2015, at 12:54 PM, Richard Sandiford <rdsandiford@googlemail.com> wrote:
>
>> It was discovered that with the attached test case compiled with -O2
>> -funroll-loops, the regrename pass renamed one of the registers ($2)
>> to $8 that was not saved by the prologue.
>>
>> The attached patch fixes it by defining macro HARD_REGNO_RENAME_OK
>> that returns zero iff the current function is an interrupt handler and
>> a register was never live.
> You also need to do the same thing for TARGET_HARD_REGNO_SCRATCH_OK,
> to stop peephole2 from using unsaved registers as scratch registers.
>
> I should dig out my patches to clean up this interface. It's just
> too brittle to have two macros that say what registers can be used
> after reload.
Gosh, I don’t like the interface of them at all. I have interrupt functions and I want all the goodness out of gcc and I want gcc to just know that it can’t use registers it doesn’t want to save for any reason that the port marked as saved by the calling api of the function. :-( Very few ports (3) define TARGET_HARD_REGNO_SCRATCH_OK and many port (19 or so) don’t define this but do seem to have interrupt functions. The existing documentation seems not give be enough information to let me decide if I need to define it or not. I read through all the ports that do define it, and none of them shed any light on to allow me to decide if my port needs to or not.
So, first question is, are the 16 other ports that have interrupt functions and don’t define this just buggy (or non-optimal)? How can I tell if I need to or not? A single example of that does cause a port to see it and a single example of why a port would not need to define it would be instructive.
Along the lines of TARGET_CALL_FUSAGE_CONTAINS_NON_CALLEE_CLOBBERS, I’d be willing to explain the required abi of each function, and then I just want gcc to just work. All functions are normal, except for interrupt functions, all allocatable register need to be saved. I think this is a universally true thing, and it just happens to be true on my port as well.
Anyway, I’d love to see gcc improved in this area.
This one is a pet peeve of mine as I’ve seen what happens to software when a single register that should have been saved, wasn’t. It was slightly annoying to track down and find. Fixing was trivial.