[LLVMdev] RFC: Merge MCSymbol with MCSymbolData, optimizing for object file emission
Duncan P. N. Exon Smith
dexonsmith at apple.com
Wed May 13 15:25:21 PDT 2015
> On 2015 May 13, at 15:10, David Blaikie <dblaikie at gmail.com> wrote:
>
>
>
> On Wed, May 13, 2015 at 2:48 PM, 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.
>
> I've no real idea if it's the right direction - but I was certainly mystified by the various indirections here a while back (when implementing DWARF compression) & made some (failed) attempts to reconcile them.
>
> You mentioned this is is a matter of optimizing for object output rather than asm output - do you have stats on how much this hurts asm output performance, then?
>
I didn't do any measurements for asm. It should have increased memory
usage of `sizeof(MCSymbolData)` for each symbol. That's an extra 5
pointers, so it should be around 3.3% memory usage increase (5/6 of the
decrease for objects).
More information about the llvm-dev
mailing list