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? 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
