[LLVMdev] How to tell whether a GlobalValue is user-defined

[Nick Kledzik]

On Aug 27, 2014, at 1:58 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:

>>> The literalN sections were developed long ago to support coalescing of
>>> unnamed constants like 9.897 in source code for architectures that could not
>>> embed large constants in instructions.  The linker could knew how to break
>>> up the section (e.g. __literal8 is always 8 byte chunks) and coalesce copies
>>> by content.
>>> 
>>> ~6 years ago we discovered that gcc would sometimes put user named
>>> constants into the literal sections (e.g. const double foo 9.897).  This was
>>> an issue because C language rules say &a != &b, but if ‘a’ and ‘b’ are the
>>> contain the same literal value from different translation units, the linker
>>> could merge them to the same address.  For whatever reason, we could not fix
>>> gcc, so we changed to linker to never coalesce items in literal sections if
>>> there was a (non ‘L’ and non ‘l’) symbol on it.
>> 
>> 
>> Thanks for the info!
> 
> +1
> 
>>> The current state of LLVM is that is it going out of its way to move
>>> “named” constants from __const section to __literalN section. But the only
>>> possible advantage to doing that is that the hopes that the linker might
>>> coalesce it.  But the linker won’t coalesce it because it is named.  So, is
>>> there a way to keep the named values in the __const section?
>> 
>> 
>> Right, LLVM has proven that the address of the data is insignificant, hence
>> it is "unnamed", and can be placed in a mergeable section. Is there any
>> reason not to change the linker to merge this stuff, if gcc is no longer
>> supported? We won't violate the semantics of C. Is there some immediate
>> problem with keeping the data in these sections?
> 
> 
> Agreed. If ld64 can drop support for .o produced by the old gcc that
> would be awesome. Failing that, what is really needed is
Because of static archives, the linker has to support old .o files for quite a while.   I also don’t know when clang starting getting this right.

Also, this seems like linker complexity for a very unlikely optimization (two named constants with same value).  If someone cares about this level of optimization, they can use LTO which will do all the constant merging in LLVM.  

> 
> LLVM should only put constants in mergeable sections only if (among
> other things) they require only symbols that start with 'l' or 'L'.
Not sure what you mean here. What is "requiring”?  Are we talking about this code in TargetLoweringObjectFileMachO::SelectSectionForGlobal()

 if (Kind.isMergeableConst()) {
    if (Kind.isMergeableConst4())
      return FourByteConstantSection;
    if (Kind.isMergeableConst8())
      return EightByteConstantSection;
    if (Kind.isMergeableConst16())
      return SixteenByteConstantSection;
  }

Can’t we just change the first ‘if’ to:

 if (Kind.isMergeableConst() && !GV.hasName()) {

That should leave any “named” constants in the __const section instead of moving them to the __literal section. (Though I don’t actually know if anonymous constants were given some name earlier so hasName() is useless at this point).

-Nick