<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 4, 2017 at 2:04 PM, Mehdi Amini <span dir="ltr"><<a href="mailto:mehdi.amini@apple.com" target="_blank">mehdi.amini@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div class="m_6649674883141031626h5"><br><div><blockquote type="cite"><div>On Apr 4, 2017, at 1:40 PM, Peter Collingbourne <<a href="mailto:peter@pcc.me.uk" target="_blank">peter@pcc.me.uk</a>> wrote:</div><br class="m_6649674883141031626m_-1978259243830008918Apple-interchange-newline"><div><br class="m_6649674883141031626m_-1978259243830008918Apple-interchange-newline"><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_quote" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">On Tue, Apr 4, 2017 at 1:25 PM, Mehdi Amini<span class="m_6649674883141031626m_-1978259243830008918Apple-converted-space"> </span><span dir="ltr"><<a href="mailto:mehdi.amini@apple.com" target="_blank">mehdi.amini@apple.com</a>></span><span class="m_6649674883141031626m_-1978259243830008918Apple-converted-space"> </span><wbr>wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><br><div><div><div class="m_6649674883141031626m_-1978259243830008918m_-7875035755744960011h5"><blockquote type="cite"><div>On Apr 4, 2017, at 12:12 PM, Peter Collingbourne <<a href="mailto:peter@pcc.me.uk" target="_blank">peter@pcc.me.uk</a>> wrote:</div><br class="m_6649674883141031626m_-1978259243830008918m_-7875035755744960011m_-8590105817118220816Apple-interchange-newline"><div><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_extra"><div class="gmail_quote">On Mon, Apr 3, 2017 at 8:13 PM, Mehdi Amini<span class="m_6649674883141031626m_-1978259243830008918m_-7875035755744960011m_-8590105817118220816Apple-converted-space"> </span><span dir="ltr"><<a href="mailto:mehdi.amini@apple.com" target="_blank">mehdi.amini@apple.com</a>></span><span class="m_6649674883141031626m_-1978259243830008918m_-7875035755744960011m_-8590105817118220816Apple-converted-space"> </span><wbr>wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><br><div><span class="m_6649674883141031626m_-1978259243830008918m_-7875035755744960011m_-8590105817118220816m_-3918021130855566634gmail-"><blockquote type="cite"><div>On Apr 3, 2017, at 7:08 PM, Peter Collingbourne <<a href="mailto:peter@pcc.me.uk" target="_blank">peter@pcc.me.uk</a>> wrote:</div><br class="m_6649674883141031626m_-1978259243830008918m_-7875035755744960011m_-8590105817118220816m_-3918021130855566634gmail-m_-7006201566700826442Apple-interchange-newline"><div><div dir="ltr">Hi,<div><br></div><div>As part of PR27551 I want to add a string table to the bitcode format to allow global value and comdat names to be shared with the proposed symbol table (and, as side effects, allow comdat names to be shared with value names, make bitcode files more compressible and make bitcode easier to parse). The format of the string table would be a top-level block containing a blob containing null-terminated strings [0] similar to the string table format used in most object files. </div></div></div></blockquote><div><br></div><div><br></div></span><div>I’m in favor of this, but note that currently string can be encoded with less than 8 bits / char in some cases (there might some size increase because of this).</div></div></div></blockquote><div><br></div><div>Sure, but I think we need to make the right tradeoff between making data more efficient to read and using fewer bits. In this case I think the right tradeoff is clearly in favour of being efficient to read, because accessing it is in the critical path of a consumer (i.e. a linker), and the part that needs to be efficient to read is a relatively small part of the data in the bitcode file. The same logic applies to the symbol table (note that we use support::ulittle32_t instead of a bit encoding).</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div>That said we already paid this with the metadata table in the recent past for example.</div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><span class="m_6649674883141031626m_-1978259243830008918m_-7875035755744960011m_-8590105817118220816m_-3918021130855566634gmail-"><br><blockquote type="cite"><div><div dir="ltr"><div>The format of MODULE_CODE_{FUNCTION,GLOBALVA<wbr>R,ALIAS,IFUNC,COMDAT} records would change so that their first operand would specify their names with a byte offset into the string table. (To allow for backwards compatibility, I would increment the bitcode version.)</div></div></div></blockquote><div><br></div></span><div>I assume you mean the EPOCH?</div></div></div></blockquote><div><br></div><div>No, the MODULE_CODE_VERSION.</div><div><a href="http://llvm-cs.pcc.me.uk/lib/Bitcode/Writer/BitcodeWriter.cpp#3822" target="_blank">http://llvm-cs.pcc.me.uk/lib/B<wbr>itcode/Writer/BitcodeWriter.cp<wbr>p#3822</a></div><div>It isn't clear to me why we have both.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><span class="m_6649674883141031626m_-1978259243830008918m_-7875035755744960011m_-8590105817118220816m_-3918021130855566634gmail-"><br><blockquote type="cite"><div><div dir="ltr"><div>Here is what it would look like as bcanalyzer output:</div><div><br></div><div><MODULE_BLOCK></div><div> <span class="m_6649674883141031626m_-1978259243830008918m_-7875035755744960011m_-8590105817118220816Apple-converted-space"> </span><VERSION op0=2></div><div> <span class="m_6649674883141031626m_-1978259243830008918m_-7875035755744960011m_-8590105817118220816Apple-converted-space"> </span><COMDAT op0=0 ...> ; name = foo</div><div> <span class="m_6649674883141031626m_-1978259243830008918m_-7875035755744960011m_-8590105817118220816Apple-converted-space"> </span><FUNCTION op0=0 ...> ; name = foo</div><div> <span class="m_6649674883141031626m_-1978259243830008918m_-7875035755744960011m_-8590105817118220816Apple-converted-space"> </span><GLOBALVAR op0=4 ...> ; name = bar</div><div> <span class="m_6649674883141031626m_-1978259243830008918m_-7875035755744960011m_-8590105817118220816Apple-converted-space"> </span><ALIAS op0=8 ...> ; name = baz</div><div> ; function bodies, etc.<br></div><div></MODULE_BLOCK></div><div><STRTAB_BLOCK></div><div> <span class="m_6649674883141031626m_-1978259243830008918m_-7875035755744960011m_-8590105817118220816Apple-converted-space"> </span><STRTAB_BLOB blob="foo\0bar\0baz\0"></div><div></STRTAB_BLOCK></div></div></div></blockquote><div><br></div></span><div>Why is the string table after the module instead of before?</div></div></div></blockquote><div><br></div><div>For implementation simplicity. The idea is that the BitcodeWriter would have a member of type StringTableBuilder which would accumulate strings while writing the bitcode module(s) (and symtab in the future). At the end, the client would call something like BitcodeWriter::writeStrtab() which would write out the string table.</div></div></div></div></div></blockquote><div><br></div></div></div><div>There is already a traversal of the module for value numbering, building the StringTable at the same time seems quite natural to me.</div></div></div></blockquote><div><br></div><div>Other modules in the same bitcode file may need to add names to the string table, and the symbol table builder may also need to add mangled names. Trying to impose an ordering on all of those components doesn't seem worth it in my opinion.</div></div></div></blockquote><div><br></div></div></div></div>I’d stick with a single table per module, to be able to preserve the ability to perform binary split of modules.</div></blockquote><div><br></div><div>We can still extract individual modules by concatenating the module and the string table.</div><div><br></div><div>Thanks,</div></div>-- <br><div class="m_6649674883141031626gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">-- <div>Peter</div></div></div>
</div></div>