RFC: Merge MCSymbol with MCSymbolData, optimizing for object file emission

Duncan P. N. Exon Smith dexonsmith at apple.com
Fri May 15 17:08:27 PDT 2015


> On 2015-May-15, at 16:22, Jim Grosbach <grosbach at apple.com> wrote:
> 
> Cool. This seems eminently reasonable and the memory savings are pretty compelling.
> 
> LGTM.

Thanks!  Committed the main patch in r237490.

> -Jim
> 
>> On May 15, 2015, at 4:18 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote:
>> 
>> +llvm-commits, bcc:llvmdev
>> 
>>> On 2015-May-13, at 14:48, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote:
>>> 
>>> Right now MC is optimized for emitting assembly, but as Rafael pointed
>>> out to me over IRC the optimized path should be emitting object files.
>>> 
>>> This WIP patch moves MCSymbolData into MCSymbol.h and makes it a
>>> field inside MCSymbol.  This eliminates a pointer from MCSymbolData back
>>> to MCSymbol, the DenseMap<const MCSymbol *, MCSymbolData *> in
>>> MCAssembler, and converts the iplist in MCAssembler into a std::vector
>>> (along with some churn to pass around MCSymbols instead of
>>> MCSymbolData).  As a result, during object emission we save ~6 pointers
>>> per MCSymbol, eliminate lookup indirection between MCSymbol and
>>> MCSymbolData, and avoid allocation overhead for MCSymbolData.
>>> 
>>> I've measured ~4% memory savings on `llc` with this patch (using the
>>> same -flto -g input as r236642 and r236629 before it), dropping memory
>>> usage from 1058 MB down to 1017 MB.
>>> 
>>> Before I clean this up and commit it (obviously in more incremental
>>> patches (and I'll do the same cleanup for MCSection)), I wanted to
>>> confirm the direction.
>>> 
>>> <symbol-data-wip.patch>
>> 
>> I went ahead and committed r237486 and r237487, which converted the
>> iplist in MCAssembler into a std::vector, and I've started to clean
>> up for commit.  (More to do still...)
>> 
>> The one patch (so far) I want pre-commit review on is 0002 -- i.e.,
>> is this direction okay? -- since the rest are just natural fallout.
>> I've attached them for reference anyway so you can see where I'm
>> headed (0001 is just moving code as prep for 0002).
>> 
>> I know Rafael's on board -- he nerd-sniped me into this -- but he's
>> on vacation ;).  Any chance of a go-ahead from someone else that's
>> spent some time in MC?
>> 
>> 
>> <0001-MC-Move-MCSymbolData-to-MCSymbol.h-NFC.patch><0002-MC-Merge-MCSymbol-and-MCSymbolData.patch><0003-MC-Change-MCAssembler-Symbols-to-store-MCSymbol-NFC.patch><0004-MC-Change-MCFragment-Atom-to-an-MCSymbol-NFC.patch><0005-MC-Use-MCSymbol-in-MCObject-IsSymbolRefDifferenceFul.patch><0006-MC-Make-MCSymbolData-Symbol-private.patch><0007-MC-Simplify-MCSymbolData-initialization-and-remove-M.patch><all.patch>
> 





More information about the llvm-commits mailing list