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

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 (87.4 KB)

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).

+llvm-commits, bcc:llvmdev

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 (8.52 KB)

0002-MC-Merge-MCSymbol-and-MCSymbolData.patch (6.02 KB)

0003-MC-Change-MCAssembler-Symbols-to-store-MCSymbol-NFC.patch (5.35 KB)

0004-MC-Change-MCFragment-Atom-to-an-MCSymbol-NFC.patch (12.7 KB)

0005-MC-Use-MCSymbol-in-MCObject-IsSymbolRefDifferenceFul.patch (8.44 KB)

0006-MC-Make-MCSymbolData-Symbol-private.patch (64.5 KB)

0007-MC-Simplify-MCSymbolData-initialization-and-remove-M.patch (5.83 KB)

all.patch (85.6 KB)