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