[LLVMdev] How to tell whether a GlobalValue is user-defined
Rafael Espíndola
rafael.espindola at gmail.com
Wed Aug 27 21:13:39 PDT 2014
>> 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>
More information about the llvm-dev
mailing list