> On Sep 21, 2020, at 2:22 PM, Qing Zhao via Gcc-patches
> <gcc-patches@gcc.gnu.org> wrote:
>
>
>
>> On Sep 21, 2020, at 2:11 PM, Richard Sandiford <richard.sandif...@arm.com>
>> wrote:
>>
>> Qing Zhao <qing.z...@oracle.com> writes:
>>>> 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?
>>
>> The point is that we're trying to implement this in a target-independent
>> way, like for most compiler features. If the option doesn't work for a
>> particular target, then that's a bug like any other. The most we can
>> reasonably do is:
>>
>> (a) try to implement the feature in a way that uses all the appropriate
>> pieces of compiler infrastructure (what we've been discussing)
>>
>> (b) add tests for the feature that run on all targets
>>
>> It's possible that bugs could slip through even then. But that's true
>> of anything.
>>
>> Targets like x86 support many subtargets, many different compilation
>> modes, and many different compiler features (register asms, various
>> fancy function attributes, etc.). So even after the option is
>> committed and is supposedly supported on x86, it's possible that
>> we'll find a bug in the feature on x86 itself.
>>
>> I don't think anyone would suggest that we should warn the user that the
>> option might be buggy on x86 (it's initial target). But I also don't
>> see any reason for believing that a bug on x86 is less likely than
>> a bug on other targets.
>
> Okay, then I will add the default implementation as you suggested. And also
> provide the overriden optimized implementation on X86.
For X86, looks like that in addition to stack registers (st0 to st7), mask
registers (k0 to k7) also do not need to be zeroed, and also “mm0 to mm7”
should Not be zeroed too.
As I checked, MASK_REG_P and MMX_REG_P are x86 specific macros, can I use them
in middle end similar as “STACK_REG_P”?
Qing
>
> Let me know if you have further suggestion.
>
> Qing
>>
>> Thanks,
>> Richard