[PATCH] D41297: [ThinLTO] Implement summary visualizer

[Mehdi AMINI via Phabricator via llvm-commits]

mehdi_amini added a comment.

In https://reviews.llvm.org/D41297#974984, @tejohnson wrote:

> In https://reviews.llvm.org/D41297#974946, @mehdi_amini wrote:
>
> > 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
> >
> >
> > None of these seems like API guarantee to me, it sounds like "this is what actually happens in practice today in this particular workflow".
>
>
> It seems it must be a guarantee of the LTO API, since ThinLTO.ModuleMap holds the BitcodeModule objects and accesses their buffers through and after the thin link.


Right, but the combined index lives in include/llvm/IR/ModuleSummaryIndex.h and the strings are populated when loading the index/bitcode in lib/Bitcode/Reader/BitcodeReader.cpp.
None of these have anything to do with LTO or the LTO API.

>> Can I write a tool that is using the ModuleSummaryIndexBitcodeReader (or the other entry point) to create the index and release the memory buffer that contains the bitcode?
> 
> Presumably. The CombinedIndexHook that invokes this new dot dumper is only accessed via the LTO API here. But I suppose we could get in trouble if it was invoked on the index via another tool in the future. Not sure if there is a way to prevent other than documenting this StringRef clearly.

Probably!


https://reviews.llvm.org/D41297