Rafael Espíndola
2014-Aug-27 20:58 UTC
[LLVMdev] How to tell whether a GlobalValue is user-defined
>> 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 LLVM should only put constants in mergeable sections only if (among other things) they require only symbols that start with 'l' or 'L'. Correct? Cheers, Rafael
Nick Kledzik
2014-Aug-27 21:46 UTC
[LLVMdev] How to tell whether a GlobalValue is user-defined
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 isBecause 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
Rafael Espíndola
2014-Aug-28 04:13 UTC
[LLVMdev] How to tell whether a GlobalValue is user-defined
>> 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.r123585 (Jan 16 17:19:34 2011) I think.> 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()I mean "the correspoinding symbol name will start with".> 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).That seems too strict. A private GV can have a name, but it will be printed with a 'L' or 'l' prefix, so it should not be a problem. In other words, it looks like you want something like the attached patch. Cheers, Rafael -------------- next part -------------- A non-text attachment was scrubbed... Name: t.patch Type: text/x-patch Size: 2241 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140828/7f63664d/attachment.bin>
Maybe Matching Threads
- [LLVMdev] How to tell whether a GlobalValue is user-defined
- [LLVMdev] How to tell whether a GlobalValue is user-defined
- [LLVMdev] How to tell whether a GlobalValue is user-defined
- LLD doesn't handle globals with appending linkage
- [LLVMdev] Question about linking llvm-mc when porting a new backend