[llvm] [MemProf] Track and report profiled sizes through cloning (PR #98382)

[Teresa Johnson via llvm-commits]

teresajohnson wrote:

> > If I understand correctly, the approach is to optionally track total size if requested. What is the overhead for this extra tracking? Can we consider making it unconditionally available all the time?
> 
> I haven't measured it, but am concerned about adding any additional memory or bitcode size overhead for something that is only used under an option. Would prefer to leave it optional and revisit this later if we find more uses for the information.

As discussed offline, to keep things simple we can include the total size field in the records, but just not carry the total size through when not requested. This avoids the need for separate record types.

I measured the bitcode size overhead when including the size unconditionally with each MIB. Even when 0 valued, i.e. with the option disabled, for a large project this caused a 2%, 82M raw, aggregate increase in the summary bitcode file sizes. I instead settled on a different format: emit all the sizes separately at the end of the alloc info record array. We either have 0 or MIB of them. This would be 0 extra overhead when there are no total sizes (without the option), except for the fact that I now need to include one extra field in each per-module alloc info indicating the number of MIBs (this already was included in the combined index alloc info record). With this I see almost 0%, 100K raw, overhead (when the option is disabled).

https://github.com/llvm/llvm-project/pull/98382