[rfc][patch] Refactoring how we handle symbols for the end of sections

[Duncan P. N. Exon Smith]

> On 2015-Mar-11, at 13:55, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
> 
> I recently refactored how we handle creating symbols for the start of
> sections. We were doing it in an ad-hoc way and producing .text files
> that were harder to read (r231898 was the main change).
> 
> With the infrastructure in place, I am now looking at the symbol
> pointing to the end of sections. They are not as common, but there are
> some issues
> 
> * We can end up printing multiple symbols with the same purpose.
> * We switch back to sections just to print them even when we could
> have printed them earlier.
> 
> The second issues is particularly problematic with
> -fno-unique-section-names, since trying to switch back to a section
> marked with ", unique" actually creates a new one.
> 
> The attached WIP patch fixes the issue. I still have to clean up some
> issues, like it changing the number of every .Ltmp* symbol, but for
> now I would like some feedback on the direction.
> 
> Is the assembly output cleanup and unifying the end section symbol
> sufficient to justify the patch? It should also make it easier to fix
> the FIXME about subsections :-)
> 
> Cheers,
> Rafael

Sounds like a nice cleanup to me, although I don't know this code
well enough to confirm.

(Off-topic, but related: a few of us were looking at some heap profiles
of clang -flto -g a week or so ago, and temp symbols, etc., are
responsible for most of the memory allocated in the backend.  At least
on Darwin, most of the symbols seem to be unnecessary and/or unused.

For example, I've attached a POC patch by Fred (ref_addr.patch).
Previously, this code:

  - created two symbol refs,
  - created Plus and Diff exprs,
  - created a temp symbol for the label of the offset, and
  - at least on Darwin, wrote out the computed offset, leaking all five
    (unnecessary) objects on the `BumpPtrAllocator` in `MCContext`.

The patch just writes out the offset directly.  This is correct on
Darwin (is `doesDwarfUseRelocationsAcrossSections()` the right check for
that?), and maybe other platforms could benefit from something similar.
Looked like a pretty significant reduction in memory usage on smaller
LTO builds; need to repro more carefully to give stats on memory
savings.

Anyone looking at memory problems with -flto -g should probably be
looking here and at similar places... I'll circle back myself as soon as
I can.)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ref_addr.patch
Type: application/octet-stream
Size: 2118 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150313/1edc28fa/attachment.obj>
-------------- next part --------------