[PATCH] D41297: [ThinLTO] Implement summary visualizer

Teresa Johnson via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Jan 12 09:42:23 PST 2018


tejohnson added a comment.

In https://reviews.llvm.org/D41297#974754, @evgeny777 wrote:

> > At which point of the API is this guarantee?
>
>
>
> 1. `ThinLTO.ModuleMap` stores `BitcodeModule` objects and uses them during entire thin link phase (until backend threads are launched)
> 2. BitcodeModule contains pointers to BC data, so this data should be actual for module to be parsed)
> 3. Module summary is exported to .dot in CombinedIndexHook which is invoked in the beginning of thin link phase


Note that the BitcodeModule itself holds a StringRef. It looks like this essentially points into the MemoryBuffer passed in as a MemoryBufferRef to InputFile::create, which is invoked by the linker. I don't recall what the guarantees are about how long that MemoryBufferRef has to stay valid. pcc may know since he added the InputFile and string table handling.

Mehdi also raises a good point that this wouldn't work if we used a tool that operated on an existing serialized combined index, which doesn't contain symbol names.

If we do have names available, as an aside, we could use them in many debugging messages that currently emit GUID during the thin link, which would be great. I just am concerned that the LTO API may need to explicitly keep these names around, in which case it would be good to do that only under a debugging option.


https://reviews.llvm.org/D41297





More information about the llvm-commits mailing list