On November 20, 2017 9:02:55 PM GMT+01:00, Sandra Loosemore <san...@codesourcery.com> wrote: >On 11/20/2017 10:34 AM, Michael Matz wrote: >> 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. > >The optimization case I'm familiar with is for targets that support -G >and GP-relative addressing modes to address small data. Generally you >can only do that if the variable is allocated in the same compilation >unit as the reference, so the compiler knows definitely where it's >placed (unless the backend also supports some other mechanism for >asserting that a variable is small data). Putting tentatively-defined >variables in common defeats that optimization.
Also we cannot raise alignment of commons and thus vectorization is pessimized (all vectorizer testcases use - fno-common). IIRC LTO promotes commons to locals. Richard. >-Sandra
