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

[David Blaikie]

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?


>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150513/e6193fff/attachment.html>