<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 4, 2017 at 7:41 AM, 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div class="gmail-h5"><br><div><blockquote type="cite"><div>On Apr 4, 2017, at 7:37 AM, Teresa Johnson <<a href="mailto:tejohnson@google.com" target="_blank">tejohnson@google.com</a>> wrote:</div><br class="gmail-m_254924094255860204Apple-interchange-newline"><div><br class="gmail-m_254924094255860204Apple-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 Mon, Apr 3, 2017 at 8:13 PM, Mehdi Amini<span class="gmail-m_254924094255860204Apple-converted-space"> </span><span dir="ltr"><<a href="mailto:mehdi.amini@apple.com" target="_blank">mehdi.amini@apple.com</a>></span><span class="gmail-m_254924094255860204Apple-converted-space"> </span><wbr>wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><br><div><span><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="gmail-m_254924094255860204m_-6344725436712899051Apple-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>That said we already paid this with the metadata table in the recent past for example.</div><span><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><span><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="gmail-m_254924094255860204Apple-converted-space"> </span><VERSION op0=2></div><div> <span class="gmail-m_254924094255860204Apple-converted-space"> </span><COMDAT op0=0 ...> ; name = foo</div><div> <span class="gmail-m_254924094255860204Apple-converted-space"> </span><FUNCTION op0=0 ...> ; name = foo</div><div> <span class="gmail-m_254924094255860204Apple-converted-space"> </span><GLOBALVAR op0=4 ...> ; name = bar</div><div> <span class="gmail-m_254924094255860204Apple-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="gmail-m_254924094255860204Apple-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><span><div><br></div><br><blockquote type="cite"><div><div dir="ltr"><div>Each STRTAB_BLOCK would apply to all preceding MODULE_BLOCKs. This means that bitcode files can continue to be concatenated with "llvm-cat -b".</div></div></div></blockquote></span></div></div></blockquote><div>Do you mean "apply to all preceding MODULE_BLOCKs that aren't followed by an intervening STRTAB_BLOCK"? I.e. when bitcode files are concatenated you presumably don't want to apply a STRTAB_BLOCK to a MODULE_BLOCK from a different input bitcode file that has its own STRTAB_BLOCK.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><span><blockquote type="cite"><div><div dir="ltr"><div>(Normally bitcode files would contain a single string table, which in multi-module bitcode files would be shared between modules.)</div><div><br></div><div>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">http://reviews.llvm.org<wbr>/D12536</a><span class="gmail-m_254924094255860204Apple-converted-space"> </span>(this may have a performance impact, so I'll measure it first).</div><div><br></div><div>Assuming that performance looks good, does this seem reasonable to folks?</div></div></div></blockquote></span></div><br><div><br></div><div>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><br></div><div>Won't the new symbol table be added before the top-level VST can be removed, i.e. you need the linkage types etc right? In that case, can the offset just be added to the new symbol table? That would be more analogous to object file symbol tables which also have an offset anyway.</div></div></div></blockquote><div><br></div></div></div></div>I’m not sure I read you correctly, isn’t it what I suggested?</div></blockquote><div><br></div><div>It is - I'm just wondering why we would consider removing the offset since other things have to be moved from the VST to a new symbol table anyway. I.e., confused by pcc's comment that this " *almost* allows us to remove the global (top-level) VST entirely, if not for the function offset in the FNENTRY record" - there are currently other things in the VST that we need to a new symbol before it can be removed, and I'm not sure why this is any different.</div><div><br></div><div>Teresa</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>— </div><span class="gmail-HOEnZb"><font color="#888888"><div>Mehdi</div><div><br></div></font></span></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><span style="font-family:times;font-size:medium"><table cellspacing="0" cellpadding="0"><tbody><tr style="color:rgb(85,85,85);font-family:sans-serif;font-size:small"><td nowrap style="border-top:2px solid rgb(213,15,37)">Teresa Johnson |</td><td nowrap style="border-top:2px solid rgb(51,105,232)"> Software Engineer |</td><td nowrap style="border-top:2px solid rgb(0,153,57)"> <a href="mailto:tejohnson@google.com" target="_blank">tejohnson@google.com</a> |</td><td nowrap style="border-top:2px solid rgb(238,178,17)"> 408-460-2413</td></tr></tbody></table></span></div>
</div></div>