
<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 Apr 4, 2017, at 12:12 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" 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; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_extra"><div class="gmail_quote">On Mon, Apr 3, 2017 at 8:13 PM, Mehdi Amini<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:mehdi.amini@apple.com" target="_blank" class="">mehdi.amini@apple.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><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;" class=""><br class=""><div class=""><span class="m_-3918021130855566634gmail-"><blockquote type="cite" class=""><div class="">On Apr 3, 2017, at 7:08 PM, Peter Collingbourne <<a href="mailto:peter@pcc.me.uk" target="_blank" class="">peter@pcc.me.uk</a>> wrote:</div><br class="m_-3918021130855566634gmail-m_-7006201566700826442Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hi,<div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class=""><br class=""></div></span><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></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;" class=""><div class=""><div class="">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;" class=""><div class=""><span class="m_-3918021130855566634gmail-"><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">The format of MODULE_CODE_{FUNCTION,GLOBALVA<wbr class="">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 class=""><br class=""></div></span><div class="">I assume you mean the EPOCH?</div></div></div></blockquote><div class=""><br class=""></div><div class="">No, the MODULE_CODE_VERSION.</div><div class=""><a href="http://llvm-cs.pcc.me.uk/lib/Bitcode/Writer/BitcodeWriter.cpp#3822" target="_blank" class="">http://llvm-cs.pcc.me.uk/lib/<wbr class="">Bitcode/Writer/BitcodeWriter.<wbr class="">cpp#3822</a></div><div class="">It isn't clear to me why we have both.</div><div class=""><br class=""></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;" class=""><div class=""><span class="m_-3918021130855566634gmail-"><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">Here is what it would look like as bcanalyzer output:</div><div class=""><br class=""></div><div class=""><MODULE_BLOCK></div><div class=""> <span class="Apple-converted-space"> </span><VERSION op0=2></div><div class=""> <span class="Apple-converted-space"> </span><COMDAT op0=0 ...> ; name = foo</div><div class=""> <span class="Apple-converted-space"> </span><FUNCTION op0=0 ...> ; name = foo</div><div class=""> <span class="Apple-converted-space"> </span><GLOBALVAR op0=4 ...> ; name = bar</div><div class=""> <span class="Apple-converted-space"> </span><ALIAS op0=8 ...> ; name = baz</div><div class=""> ; function bodies, etc.<br class=""></div><div class=""></MODULE_BLOCK></div><div class=""><STRTAB_BLOCK></div><div class=""> <span class="Apple-converted-space"> </span><STRTAB_BLOB blob="foo\0bar\0baz\0"></div><div class=""></STRTAB_BLOCK></div></div></div></blockquote><div class=""><br class=""></div></span><div class="">Why is the string table after the module instead of before?</div></div></div></blockquote><div class=""><br class=""></div><div class="">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 class=""></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><br class=""></div><div>— </div><div>Mehdi</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><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; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></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;" class=""><div class=""><span class="m_-3918021130855566634gmail-"><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">Each STRTAB_BLOCK would apply to all preceding MODULE_BLOCKs. This means that bitcode files can continue to be concatenated with "llvm-cat -b". (Normally bitcode files would contain a single string table, which in multi-module bitcode files would be shared between modules.)</div><div class=""><br class=""></div><div class="">This *almost* allows us to remove the global (top-level) VST entirely, if not for the function offset in the FNENTRY record. However, this offset is not actually required because we can scan the module's FUNCTION_BLOCK_IDs as we were doing before <a href="http://reviews.llvm.org/D12536" target="_blank" class="">http://reviews.llvm.org<wbr class="">/D12536</a><span class="Apple-converted-space"> </span>(this may have a performance impact, so I'll measure it first).</div><div class=""><br class=""></div><div class="">Assuming that performance looks good, does this seem reasonable to folks?</div></div></div></blockquote></span></div><br class=""><div class=""><br class=""></div><div class="">I rather seek to have a symbol table that entirely replace the VST, kee. If there is a perf impact with the FNENTRY offset, why can’t it be replicated in the symbol table?</div></div></blockquote><div class=""><br class=""></div><div class="">Sure, we could in principle store function offsets in the symbol table as well, if that helps with performance. But I want to measure the impact and find out whether that is actually the case first.</div><div class=""><br class=""></div><div class="">Thanks,</div></div>--<span class="Apple-converted-space"> </span><br class=""><div class="m_-3918021130855566634gmail_signature"><div dir="ltr" class="">-- <div class="">Peter</div></div></div></div></div></div></blockquote></div><br class=""></body></html>