<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 15, 2015 at 10:07 AM, Dave Bozier <span dir="ltr"><<a href="mailto:seifsta@gmail.com" target="_blank">seifsta@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><span class="">> <span style="font-size:12.8000001907349px">There is no need for emitting the full symtab. I checked the overhead with a huge internal C++ source. The overhead of symtab + str table compared with byte code with debug is about 3%.</span><div><span style="font-size:12.8000001907349px"><br></span></div></span><div>It's still sizable and could be noticeable if thinLTO can deliver compile times that closer to what resembles builds without LTO as your results suggest.</div></div></blockquote><div><br></div><div><span style="font-family:monospace">If the cost is part of the index/summary, then it is avoidable.</span><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><span class=""><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">> More importantly, it is also possible to use the symtab also for index/summary purpose, which makes the space usage completely 'unwasted'. That gets into the details which will follow when patches are in.</span></div></span></div></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><span class=""><div><span style="font-size:12.8000001907349px"><br></span></div></span><div><span style="font-size:12.8000001907349px">There is symbol information in both the native object symbol table and the bitcode file? isn't that waste? I understand the reasons for using the native object wrapper (compatibility with other tools) and happy with that. But I'd also like to see the option for function index/summary data to be produced without the wrapper, so that bitcode aware tools do not need to use this wrapped format.</span></div></div></blockquote><div><br></div><div><span style="font-family:monospace">I agree.</span></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><span style="font-size:12.8000001907349px"> </span>If you mix the native object wrapper symbol information with the function/index summary data then that would end up being impossible.</div></div></blockquote><div><br></div><br class=""><div><span style="font-family:monospace">It is possible. The summary data is still in its own proper (its own section). Under the bitcode only option, the symtab will be replaced with bitcode form of the index, while the summary remains the same. </span> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">Also won't having the native object data with the function index/summary have a cost on testing for all of the supported native object formats?</span></div></div></blockquote><div><br></div><div>yes.</div><div><br></div><div>thanks,</div><div><br></div><div>David</div><div> </div></div><br></div></div>