Michael Matz wrote:
> bss _sections_ != bss-like segments in the executable. Targets might not
> have a bss section that could be named in the asm file, or no way to
> switch to it without disrupting surrounding code, but they might have
> common symbols, which ultimately might or might not be collected in some
> bss-like segment. In that case you want to use them instead of symbols in
> .data.
OK, thanks for the explanation. For large symbols it obviously makes sense
to keep the executable size reasonable.
Is this really Ada specific and related to -fcommon? We could do this
optimization
without checking flag_no_common.
> What's your rationale for changing this? In your initial mail you said:
>
> "On many targets this means global variable accesses having an unnecessary
> codesize and performance penalty in C code (the same source generates
> better code when built as C++)."
>
> I have a hard time imaging that, so can you give details? FWIW I've
> personally always considered using common symbols nicer.
Basically -fcommon disables the anchor optimization on RISC targets,
here is a simple example on AArch64:
int a, b, c;
int f (void) { return a + b + c; }
With -fcommon:
f:
adrp x1, a
adrp x0, b
adrp x2, c
ldr w1, [x1, #:lo12:a]
ldr w0, [x0, #:lo12:b]
ldr w2, [x2, #:lo12:c]
add w0, w1, w0
add w0, w0, w2
ret
With -fno-common:
f:
adrp x0, .LANCHOR0
add x2, x0, :lo12:.LANCHOR0
ldr w1, [x0, #:lo12:.LANCHOR0]
ldp w0, w2, [x2, 4]
add w0, w1, w0
add w0, w0, w2
ret
The anchor pointer is set up once and cached across the function, making
accesses
to multiple globals cheap and enabling other optimizations. On various targets
(eg. PPC, Arm) creating the address of a global takes 2 instructions so the
savings
are larger.
Wilco
