crazy idea: Make all temporary symbols unnamed

[Nick Kledzik]

On Jun 17, 2015, at 10:28 AM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote:

> +grosbach,kledzik
> 
>> 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?
> 
> Nick?
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.  

Is this patch about heap savings during the generation of .o files? or about reducing the size of .o files?

-Nick


> 
>> If not, I think we could
>> still do this and let those object writers invent a deterministic name
>> at the very end, no?
> 
> Sounds plausible.
> 
>> I tested this locally by doing a bootstrap.
>> 
>> I tested the memory savings for llvm-mc are quite noticeable. When
>> assembly a LTO llvm-as, the memory usage goes from 45,952,208 to
>> 39,137,568 bytes.
> 
> Any memory stats for LTO codegen (bitcode => object)?
> 
>> 
>> Cheers,
>> Rafael
>> <t.patch>
>