Sorry to use another e-mail due to network issue. I tried -fsection-anchors option. But it does not apply to the target.
Best regards Clark Zhao This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! 发件人: 赵海峰 [mailto:zju....@qq.com] 发送时间: 2024年5月31日 16:51 收件人: Zhaohaifeng(Clark,CIS-HCE) <zhaohaife...@huawei.com> 主题: Fw: Re: Is fcommon related with performance optimization logic? ---Original--- From: "David Brown"<david.br...@hesbynett.no<mailto:david.br...@hesbynett.no>> Date: Thu, May 30, 2024 22:19 PM To: "Andrew Pinski"<pins...@gmail.com<mailto:pins...@gmail.com>>;"赵海峰"<zju....@qq.com<mailto:zju....@qq.com>>; Cc: "gcc"<gcc@gcc.gnu.org<mailto:gcc@gcc.gnu.org>>; Subject: Re: Is fcommon related with performance optimization logic? On 30/05/2024 04:26, Andrew Pinski via Gcc wrote: > On Wed, May 29, 2024 at 7:13 PM 赵海峰 via Gcc wrote: >> >> Dear Sir/Madam, >> >> >> We found that running on intel SPR UnixBench compiled with gcc 10.3 performs >> worse than with gcc 8.5 for dhry2reg benchmark. >> >> >> I found it related with -fcommon option which is disabled in 10.3 by >> default. Fcommon will make global variables addresses in special order in >> bss section(watching by nm -n) whatever they are defined in source code. >> >> >> We are wondering if fcommon has some special performance optimization >> process? >> >> >> (I also post the subject to gcc-help. Hope to get some suggestion in this >> mail list. Sorry for bothering.) > > This was already filed as > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114532 . But someone > needs to go in and do more analysis of what is going wrong. The > biggest difference for x86_64 is how the variables are laid out and by > who (the compiler or the linker). There is some notion that > -fno-common increases the number of L1-dcache-load-misses and that > points to the layout of the variable differences causing the > difference. But nobody has gone and seen which variables are laid out > differently and why. I am suspecting that small changes in the > code/variables would cause layout differences which will cause the > cache misses which can cause the performance which is almost all by > accident. > I suspect adding -fdata-sections will cause another performance > difference here too. And there is not much GCC can do about this since > data layout is "hard" to do to get the best performance always. > (I am most familiar with embedded systems with static linking, rather than dealing with GOT and other aspects of linking on big systems.) I think -fno-common should allow -fsection-anchors to do a much better job. If symbols are put in the common section, the compiler does not know their relative position until link time. But if they are in bss or data sections (with or without -fdata-sections), it can at least use anchors to access data in the translation unit that defines the data objects. David > Thanks, > Andrew Pinski > >> >> >> Best regards. >> >> >> Clark Zhao >
