[PATCH] D34063: [ThinLTO][llvm-lto2] Dump YAML for module summaries

Teresa Johnson via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sat Jun 10 06:42:43 PDT 2017


tejohnson added inline comments.


================
Comment at: include/llvm/IR/ModuleSummaryIndex.h:537
+  // Maps Oid GUID to the stringified value name (for dissassembly)
+  std::map<GlobalValue::GUID, std::string> OidToValueName;
+
----------------
ncharlie wrote:
> mehdi_amini wrote:
> > ncharlie wrote:
> > > mehdi_amini wrote:
> > > > Do we want this on all the time? Is this a fundamental property of the Index?
> > > > It isn't clear to me if it isn't just a debugging tool that map to the IR when available right now?
> > > How would you recommend making this an optional debugging option? Would a constructor argument work?
> > Is this information in the index in the bitcode? 
> > If not then it can be reconstructed at dump time.
> The reason I'm storing the map in the index is because I only have access to the ValueName when the bitcode is being parsed in ModuleSummaryIndexBitcodeReader (see BitcodeReader.cpp:4715 in this patch). Also, when the YAML is being generated, I'm only given a pointer to a ModuleSummaryIndex, which is why the map is in that class.
The value name is available on the GlobalValue (Value::getName()), as is the GUID (getGUID()). So you can just walk the Module's list of global_objects() (which gives you all the functions and global variables) and the list of aliases(), and compute the mapping. 

That being said, I am not familiar enough with the YAML support to know how to get an additional object (either the Module, or a mapping pre-computed by the client or a wrapper function), passed down to where you need it. pcc may have some insight.


https://reviews.llvm.org/D34063





More information about the llvm-commits mailing list