Qing Zhao <qing.z...@oracle.com> writes: > My major concern with the default implementation of the hook is: > > If a target has some special registers that should not be zeroed, and we do > not provide an overridden implementation for this target, then the default > implementation will generate incorrect code for this target.
That's OK. The default behaviour of hooks and macros often needs to be corrected by target code. For example, going back to some of the macros and hooks we talked about earlier: - EPILOGUE_USES by default returns false for all registers. This would be the wrong behaviour for any target that currently defines EPILOGUE_USES to something else. - TARGET_HARD_REGNO_SCRATCH_OK by default returns true for all registers. This would be the wrong behaviour for any target that currently defines the hook to do something else. And in general, if there's a target-specific reason that something has to be different from normal, it's better where possible to expose the underlying concept that makes that different behaviour necessary, rather than expose the downstream effects of that concept. For example, IMO it's a historical mistake that targets that support interrupt handlers need to change all of: - TARGET_HARD_REGNO_SCRATCH_OK - HARD_REGNO_RENAME_OK - EPILOGUE_USES to expose what is essentially one concept. IMO we should instead just expose the fact that certain functions have extra call-saved registers. (This is now possible with the function_abi stuff, but most interrupt handler support predates that.) So if there is some concept that prevents your new target hook being correct for x86, I think we should try if possible to expose that concept to target-independent code. And in the case of stack registers, that has already been done. The same would apply to any other target for which the default turns out not to be correct. But in cases where there is no underlying concept that can sensibly be extracted out, it's OK if targets need to override the default to get correct behaviour. Thanks, Richard
