[llvm-commits] [llvm] r66690 - in /llvm/trunk: docs/ include/llvm-c/ include/llvm/ lib/AsmParser/ lib/Bitcode/Reader/ lib/Bitcode/Writer/ lib/CodeGen/ lib/Target/ARM/AsmPrinter/ lib/Target/Alpha/AsmPrinter/ lib/Target/CellSPU/AsmPrinter/ lib/Target/CppBackend/ lib/Target/IA64/ lib/Target/Mips/ lib/Target/PowerPC/AsmPrinter/ lib/Target/Sparc/AsmPrinter/ lib/Target/X86/AsmPrinter/ lib/VMCore/ utils/ utils/vim/

[Dan Gohman]

On Mar 12, 2009, at 2:33 AM, Duncan Sands wrote:

> Hi Dan,
>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=66690&view=rev
>>> Log:
>>> It makes no sense to have a ODR version of common
>>> linkage, so remove it.
>>
>> Why does common_odr make no sense? According to LangRef.html, common
>> is the same as linkonce, except for the rules when it's unreferenced.
>
> it sounds like the LangRef description needs to be improved!  First  
> off,
> it seems that common linkage only applies to global variables, and  
> then
> only to declarations (maybe definitions with a null initializer - this
> isn't very clear [*]).  What happens at link time is:
>  (case 1) the same symbol is defined somewhere without common linkage.
> Then that definition is used.
>  (case 2) all definitions of the symbol have common linkage.  Then
> the symbol is initialized to all zero, with the size being the maximum
> size of all occurrences of the symbol, likewise for the alignment.
>
>> Is it just that C++ or other common languages don't need common_odr?
>
> Based on the above, ODR doesn't make a lot of sense.  If common  
> linkage
> only applies to declarations then ODR is irrelevant because there is  
> no
> definition.  If common linkage is allowed for null initialized globals
> then common_odr would have to mean: this symbol really is zero- 
> initialized.
> What's more, common_odr would imply that any other occurrences of  
> the symbol
> would have to have the same size or less.  That's because based on  
> common_odr
> the optimizers are allowed to assume that stores off the end of the  
> global
> are invalid (like for non-weak globals) and make simplifications  
> based on
> this.  However if other occurrences of the symbol were allowed to be  
> bigger
> then the final symbol would be bigger and writes off the end could  
> be valid;
> the optimizers would then be making an incorrect simplification  
> [this point
> could be argued...].  Thus common_odr would imply that: the final  
> symbol
> is zero initialized and the same size as this one (and at least as  
> aligned).
> In that case the front-end might as well output this global with  
> ordinary
> external linkage, outputting it with common linkage doesn't gain  
> anything!
> [Well, there is the issue of the magically increasing alignment...].

Hi Duncan,

Thanks for the explanations! I agree that given the current status
of common, common_odr doesn't seem necessary. If common is ever
extended to be more flexible, common_odr can always be re-introduced
if needed.

Dan


>
>
> Ciao,
>
> Duncan.
>
> [*] The verifier doesn't seem to be checking any of this.  Same goes
> for extern_weak linkage which can only apply to declarations it seems.
> There also seem to be a bunch of restrictions as to which linkage
> types can be applied to functions, which to global variables, which
> to declarations and which only not to declarations, but these don't
> seem to be documented.