> On Sep 21, 2020, at 10:35 AM, Richard Sandiford <richard.sandif...@arm.com>
> wrote:
>
> 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.
I will exclude “stack registers” in the middle end to see whether this can
resolve the issue with X86.
>
> 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.
Then, on the target that the default code is not right, and we haven’t provide
overridden implementation, what should we inform the end user about this?
The user might see the documentation about -fzero-call-used-regs in gcc manual,
and might try it on that specific target, but the default implementation is not
correct, how to deal this?
Qing
>
> Thanks,
> Richard
