[LLVMdev] Debug info: type uniquing for C++ and the status on building clang with "-flto -g"
Sean Silva
chisophugis at gmail.com
Tue Nov 12 18:54:22 PST 2013
On Tue, Nov 12, 2013 at 3:42 PM, Manman Ren <manman.ren at gmail.com> wrote:
>
> Hi All,
>
> Type uniquing for C++ is in. Some data for Xalan with -flto -g:
> 9.9MB raw dwarf size, peak memory usage at 2.8GB
> The raw dwarf size was 58MB, memory usage was 7GB back in May, 2013.
> Other efforts at size reduction helped, and type uniquing improved on top
> of those.
>
> Data on building clang with "-flto -g" after type uniquing:
> 3.4GB MDNodes after parsing all bc files, 7GB MDNodes after linking all
> bc files
> 4.6GB DIEs
> 4G MCContext
> --> The memory usage is still too big.
>
What fraction of the memory space occupied by MDNodes is just pointers?
(IIRC our whole scheme for metadata is the epitome of "sea of linked
nodes"). Do you have any statistics of how often the flexibility offered by
links is used? (e.g. how often the links are changed). If huge swaths of
these nodes are read-mostly, then it may be much more efficient to use a
representation where the links are implicit.
More generally, can you gather some statistics about the relative
distribution of different operations on MDNodes that we do? (what is the
most called method? are there a couple of methods that account for >90% of
calls? How often do we mutate this data? etc.)
-- Sean Silva
>
> So how to reduce the memory footprint at MDNode level:
> 1> Combine integers into MDString and further combining MDStrings (see
> PR17891)
> A partial implementation on the important debug info nodes can
> reduce the MDNodes from 7GB to 5.7GB
> 2> Release MDNodes that are only used by source modules (I will send out
> a proposal)
> An estimation based on partial implementation: this will reduce
> MDNodes from 5.7GB to 3.9GB
>
> Thanks,
> Manman
>
>
>
>
>
> _______________________________________________
> 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/20131112/7eeff946/attachment.html>
More information about the llvm-dev
mailing list