[Bug middle-end/114532] gcc -fno-common option causes performance degradation on certain architectures

["david at westcontrol dot com" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114532

--- Comment #7 from David Brown <david at westcontrol dot com> ---
(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.