https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112470
--- Comment #6 from John Dong <dongjianqiang2 at huawei dot com> --- (In reply to Richard Sandiford from comment #5) > Could you quantify the performance impact that you're seeing? Figures > relative to no protection and to unpatched -fstack-protector-strong would be > useful. > > -fstack-protector-strong adds a large overhead to small functions like this > [https://godbolt.org/z/x1v7hvsq1]. And the option explicitly asks for > statically sized arrays to be “protected”. Users who only want > variable-length arrays to be protected would instead use -fstack-protector. > > So given that the function has the kind of array that the user wants to be > protected, it seems safer to provide the same kind of protection as other > targets do, in the same way, rather than try to do our own thing. We've > already been bitten once by this. > > For example, on other targets, -fstack-protector-strong effectively protects > against underflow as well as overflow, in the sense that underflow can't > overwrite the function's saved registers. The proposed patch would change > that for AArch64: writing at negative indices would allow the saved > registers to be overwritten. For applications without stack protection, there is no difference because the function stack frame not changed when aarch64_save_regs_above_locals_p is false. I didn't run any spec tests, but I saw about a 0.5% CPU usage increasing for some applications between patched -fstack-protector-strong and unpatched -fstack-protector-strong.
