[llvm] [MemProf] Print full context hash when reporting hinted bytes (PR #114465)

[Teresa Johnson via llvm-commits]

teresajohnson wrote:

Update on overhead: I didn't see any significant time overheads, but the thin link had about 18% memory overhead and the bitcode IR+summary objects were about 8.5% larger (with summary ~30% larger). I did some work to reduce this overhead, with the following 2 realizations:
- We were keeping the context id / size pairs in a global table in the in-memory and bitcode formats, and referring to them by index.  This was meant to enable deduplication (e.g. when allocation have been cloned due to inlining, etc), but it turns out that this was inefficient on aggregate as there aren't that many deduplication opportunities in practice in the large profile I examined. I got improvements in both metrics by removing the separate tables and including the context id / size pairs directly in the allocation info summaries.
- I then realized that the context id hashes are almost always nearly 64-bits in size, so the VBR8 encoding is not the most efficient, and a fixed width encoding is better overall. To enable encoding the context ids with a fixed width, I then pulled out the context ids into separate records, one per alloc info record, with the context ids listed in the same order as the sizes in the immediately following alloc info record to enable implicit correlation for reconstruction of the pairs when reading the bitcode. This reduced the bitcode sizes a bit further. Note that the largest fixed width size supported by the bitcode is 32 bits, so we record each context id as a pair of 32-bit fixed width values (this is the same approach taken for value GUIDs elsewhere in the summary).

With these improvements, we now have a bit less than 10% memory overhead and about 7.5% larger bitcode IR+summary objects (with summary about 22% larger).

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