On Tue, Sep 22, 2020 at 11:25 AM Qing Zhao <qing.z...@oracle.com> wrote: > > 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?) >
No particular reason. You can add them. H.J.
