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.
Thanks,
Richard
