crazy idea: Make all temporary symbols unnamed
peter_cooper at apple.com
Wed Jun 17 14:05:42 PDT 2015
> On Jun 17, 2015, at 1:56 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote:
>> On 2015 Jun 17, at 13:51, Nick Kledzik <kledzik at apple.com> wrote:
>> On Jun 17, 2015, at 10:28 AM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote:
>>>> On 2015 Jun 17, at 10:09, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
>>>> The attached patch is a work in progress.
>>>> What it does is make all symbols that would otherwise start with a .L
>>>> (or L on MachO) unnamed.
>>>> There are two issues to be aware of:
>>>> * Some of these symbols can show up in the symbol table.
>>>> * We still want to produce binary identical files when going through
>>>> assembly files.
>>>> If the first one is handled, the second one goes away by making sure
>>>> we ignore the name of *all* .L symbols: we pick one when writing
>>>> assembly, but it never shows up in the final .o.
>>> How do the 'l' symbols fit into this? Unaffected, right?
>>>> In this patch I have handled the first issue only in the ELF writer by
>>>> supporting unnamed symbols.
>>>> Can symbols be unnamed on COFF and MachO?
>> In general ‘L’ symbols are assembler-time symbols. They don’t make it into the .o file.
>> Are you asking if in the few places where ‘L’ symbols make into the .o file, can their names be changed to be the empty string? If so, as long as the symbols are non-external, they can have duplicate names (for instance you can have a static function _foo in two .o files and use ld -r to merge them and the two static _foo symbols continue to work properly).
>> I don’t know off hand if anything will break if you have some nlist entries point to an empty string.
> Based on this:
> https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/MachORuntime/index.html#//apple_ref/c/tag/nlist_64 <https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/MachORuntime/index.html#//apple_ref/c/tag/nlist_64>
> it seems like empty strings are allowed, so if duplicate names are fine
> too then it seems worth a try.
>> Is this patch about heap savings during the generation of .o files? or about reducing the size of .o files?
> I think more about heap savings and cleaning up the code when generating
> object files.
I tired Rafael’s patch on the verify-uselistorder.lto.opt.bc test on MachO. I didn’t make any changes as it looks like it should just work as it.
Results are a drop from 814MB peak llc memory to 804MB. Very nice Rafael!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-commits