
<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Oct 25, 2016, at 6:28 PM, Peter Collingbourne <<a href="mailto:peter@pcc.me.uk" class="">peter@pcc.me.uk</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hi all,<div class=""><br class=""></div><div class="">As mentioned in my recent RFC entitled "RFC: a more detailed design for ThinLTO + vcall CFI" I would like to introduce the ability for bitcode files to contain multiple modules. In <a href="https://reviews.llvm.org/D24786" class="">https://reviews.llvm.org/D24786</a> I took a step towards that by proposing a change to the module format so that the block info block is stored at the top level. The next step is to think about what the API would look like for reading and writing multiple modules.</div><div class=""><br class=""></div><div class="">Here's what I have in mind. To create a multi-module bitcode file, you would create a BitcodeWriter object and add modules to it:</div><div class=""><br class=""></div><div class="">BitcodeWriter W(OS);</div><div class="">W.addModule(M1);</div><div class="">W.addModule(M2);</div><div class="">W.write();</div></div></div></blockquote><div><br class=""></div><div>That requires the two modules to lives longer than the bitcode write, the API could be:</div><div><br class=""></div><div>BitcodeWriter W(OS);<br class="">W.writeModule(M1);</div><div>// delete M1</div><div>// ...</div><div>// create M2<br class="">W.writeModule(M2);<br class=""><br class=""></div><div>(Maybe you had this in mind, but the API naming didn’t reflect it so I’m not sure).</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">Reading a multi-module bitcode file would be supported with a BitcodeReader class. Each of the functional reader APIs in ReaderWriter.h would have a member function on BitcodeReader. We would also have a next() member function which would move to the next module in the file. For example:</div><div class=""><br class=""></div><div class="">BitcodeReader R(MBRef);</div><div class="">Expected<bool> B = R.hasGlobalValueSummary();<br class=""></div><div class=""><div class="">std::unique_ptr<Module> M1 = R.getLazyModule(Ctx); // lazily load the first module</div></div><div class=""><div class="">R.next();</div></div><div class=""><div class=""><div class="">std::unique_ptr<Module> M2 = R.parseBitcodeFile(Ctx); // eagerly load the second module</div></div></div></div></div></blockquote><div><br class=""></div><div><br class=""></div><div>That makes the API quite stateful, you may have good implementation reason for this, but they’re not clear to me.</div><div>I rather see the bitcode reader as a random access container, iterating over modules.</div><div><br class=""></div><div>— </div><div>Mehdi</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class=""><div class=""><br class=""></div>We'd continue to support the existing functional APIs in ReaderWriter.h for convenience in the common case where the bitcode file has a single module.</div></div><div class=""><br class=""></div><div class="">Thanks,<br class="">-- <br class=""><div class="gmail_signature"><div dir="ltr" class="">-- <div class="">Peter</div></div></div>

</div></div>

</div></blockquote></div><br class=""></body></html>