> On Sep 22, 2020, at 1:35 PM, H.J. Lu <hjl.to...@gmail.com> wrote:
>
> On Tue, Sep 22, 2020 at 11:25 AM Qing Zhao <qing.z...@oracle.com
> <mailto: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.
Okay, thanks.
Then I guess that the reason we didn’t zero mask registers and mm0-7 registers
on x86 is mainly for the performance consideration.
There might not be too much benefit for mitigating ROP attack if we zero these
additional registers, but we will got much more performance overhead.
What’s you opinion, Richard?
Qing
>
> H.J.
