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

Charles Saternos via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Jun 12 13:13:38 PDT 2017


ncharlie 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;
+
----------------
mehdi_amini wrote:
> tejohnson wrote:
> > 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.
> > 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.
> 
> Then just modify the YAML to get an optional  `Module *` as well? If you get it then you have names available, otherwise not.
> Since it wouldn't roundtrip the YAML, I'd display it as a comment next to the GUID.
> 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()

> Then just modify the YAML to get an optional  Module * as well? 

OK, I'll look into to this. I didn't realize there was already a map that stored the names in the Module class, so now I really want to get rid of my duplicate.


https://reviews.llvm.org/D34063





More information about the llvm-commits mailing list