On Aug 15, 2015, at 3:32 AM, Richard Sandiford <rdsandif...@googlemail.com>
wrote:
>
> The port is only buggy if they have define_peephole2s with match_scratches
> and those match_scratches require a register that would be saved by
> an interrupt function. In other cases defining T_H_R_S_O would have
> no effect (but still be a good idea for future proofing -- obviously
> someone who adds a new define_peephole2 is unlikely to be thinking
> about inerrupt functions).
Yeah, that was my reading of the code after I posted as well. My port was
buggy. :-( I think all the other ports like likely buggy or suboptimal.
> The main problem is that we then have three sets of registers:
> - the ABI call-clobbered set
> - the call-clobbered set for the current function
> - the set of registers that are clobbered by an already-compiled function
> (for -fipa-ra)
>
> I think that's valid, but you obviously have to be very careful to use
> the right one. Especially when it comes to cached derived information.
No. Being very careful isn’t the right solution. It should be impossible to
use the wrong one.
Something like static inline call_used (regno, call_abi = 0) { return
call_used[call_abi][regno]; } where callers that want the call_used for a given
function would call call_used (regno, fndecl) and fndecl can convert over to a
call_abi or possibly something like fndecl->call_used[regno] where most callers
can just use cfun->call_used[regnp] is the right one. It is fine for ports
without interrupt functions (because call_abi defaults to 0), and it is the
right one to use on ports with interrupt functions. In the later, the
interrupt function will have its call_abi set appropriately. Ports that
already have and manage call_abi today will notice they even like the new
scheme. And the TARGET_CALL_FUSAGE_CONTAINS_NON_CALLEE_CLOBBERS code I think
could benefit from this as well.
