Hi, Hongjiu,
> On Sep 22, 2020, at 11:31 AM, Richard Sandiford <richard.sandif...@arm.com> > wrote: > > Qing Zhao <qing.z...@oracle.com> writes: >>> 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”? > > No, those are x86-specific like you say. > > Taking each in turn: what is the reason for not clearing mask registers? > And what is the reason for not clearing mm0-7? In each case, is it a > performance or a correctness issue? Could you please provide more information on the above questions? (Why we exclude mask registers and mm0-7 registers from ALL on x86?) thanks. Qing > > Although the registers themselves are target-specific, the reason > for excluding them might be something that could be exposed to > target-independent code. > > As a general comment, with at least three sets of excluded registers, > the “all” in one of the suggested option values is beginning to feel > like a misnomer. (Maybe that has already been dropped though.) > > Thanks, > Richard
