> 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.
Let me know if you have further suggestion.
Qing
>
> Thanks,
> Richard
