https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114532
--- Comment #8 from Zhaohaifeng <zhaohaifeng4 at huawei dot com> --- (In reply to David Brown from comment #7) > (In reply to Xi Ruoyao from comment #6) > > (In reply to Zhaohaifeng from comment #5) > > > > > Does gcc implement -fsection-anchors like function in -fcommon option for > > > x86? In general concept, gcc should has some similar feature for x86 and > > > ARM. > > > > AFAIK, -fsection-anchors and -fcommon / -fno-common are completely > independent. But section anchors cannot work with "common" symbols, no > matter what architecture, because at compile time the compiler does not know > the order of allocation of the common symbols. It /does/ know the order of > allocation of symbols defined in the current translation unit, such as > initialised data, -fno-common zero initialised data, and static data. This > information can be used with section anchors and also with other > optimisations based on the relative positions of objects. > > > AFAIK it's not very useful for CISC architectures supporting variable-length > > fancy memory operands. > > That seems strange to me. But I know very little about how targets such as > x86-64 work for global data that might be complicated with load-time or > run-time linking - my experience and understanding is all with statically > linked binaries. > > It seems, from my brief testing, that for the x86-64 target, the compiler > does not do any optimisations based on the relative positions of data > defined in a unit (whether initialised, non-common bss, or static). For > targets such as the ARM, gcc can optimise as though the individual variables > were fields in a struct where it knows the relative positions. I don't see > any reason why x86-64 should not benefit from some of these, though I > realise that scheduling and out-of-order execution will mean some apparent > optimisations would be counter-productive. Maybe there is some kind of > address space layout randomisation that is playing a role here? > > > Anyway, I cannot see any reason while -fno-common should result in the > slower run-times the OP saw (though I have only looked at current gcc > versions). I haven't seen any differences in the code generated for > -fcommon and -fno-common on the x86-64. And my experience on other targets > is that -fcommon allows optimisations that cannot be done with -fno-common, > thus giving faster code. > > I have not, however, seen the OP's real code - I've just made small tests. The difference generated for -fcommon and -fno-common is just the global variable order in memory address. -fcommon is as following (some special order): stderr@GLIBC_2.2.5 completed.0 Begin_Time Arr_2_Glob Ch_2_Glob Run_Index Microseconds Ptr_Glob Dhrystones_Per_Second End_Time Int_Glob Bool_Glob User_Time Next_Ptr_Glob Arr_1_Glob Ch_1_Glob -fno-common is as following (reversed order of source code): stderr@GLIBC_2.2.5 completed.0 Dhrystones_Per_Second Microseconds User_Time End_Time Begin_Time Reg Arr_2_Glob Arr_1_Glob Ch_2_Glob Ch_1_Glob Bool_Glob Int_Glob Next_Ptr_Glob Ptr_Glob Run_Index
