crazy idea: Make all temporary symbols unnamed

[Pete Cooper]

BTW, MachO is already skipping non-linker visible symbols in all loops in computeSymbolTable.  So I think this is totally safe to do there.

For example:

for (const MCSymbol &Symbol : Asm.symbols()) {
    if (!Asm.isSymbolLinkerVisible(Symbol))
      continue;

    StringTable.add(Symbol.getName());
  }

Pete
> 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?
> 
>> 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>
>