<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Wed, Nov 28, 2018 at 3:17 PM Kostya Serebryany <<a href="mailto:kcc@google.com">kcc@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br>Seems easier to me to separate the two pieces - move ahead with the non-zero options, and separate the discussion on the zero option. You can present performance numbers from what you can measure without shipping a compiler with the feature - and if those numbers are sufficiently compelling compared to the risks of slicing the language, then perhaps we go that way.<br></div></div></div></blockquote><div><br></div></div></div><div dir="ltr"><div class="gmail_quote"><div>This approach will significantly impair my ability to do the measurements I need. </div></div></div></blockquote><div><br>I'm aware waht I'm proposing would make it more difficult for some people to take measurements - that's a tradeoff to be sure - one where I err in this direction.<br><br>Specifically for Google though - would it be that difficult for Google to opt-in to a certain build configuration of LLVM? </div></div></div></blockquote><div><br></div></div></div><div dir="ltr"><div class="gmail_quote"><div>Absolutely yes. </div><div>Google is not just a single <a href="http://delivery.acm.org/10.1145/2860000/2854146/p78-potvin.pdf?ip=104.133.8.94&id=2854146&acc=OA&key=4D4702B0C3E38B35%2E4D4702B0C3E38B35%2E4D4702B0C3E38B35%2E5945DC2EABF3343C&__acm__=1543446999_3aadcd36f657e2297430c38bee93f16c" target="_blank">monolithic code base</a>. </div></div></div></blockquote><div><br>Couldn't access this link ("An error occurred while processing your request" - but yeah, I understand there's a bunch of different pieces of Google beyond the "stuff that runs in data centers" piece we mostly support.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>Besides that monolithic thing, we have Android, Chrome, ChromeOS, Fuchsia, and a bazillion of smaller efforts that use their own toolchains. </div></div></div></blockquote><div><br>Still, most/all of these build their own compilers, I think? But yeah, that adds an opt-in overhead to each project, for sure.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>In some cases the most reliable and complete way of measuring performance changes is to submit the changes to revision control, <br></div><div>and let the performance bots shew it for a couple of days. That's how we iterated with the LLVM's CFI in Chrome. </div><div>We will also need to work with the upstream Linux kernel -- it's hard enough for them to use clang and a modified clang will cost us much more effort. <br></div></div></div></blockquote><div><br>Yeah, I can imagine that one's a bit trickier - how's performance evaluation of the kernel done? (though, again, I imagine a fair amount of progress could be made without the zero-init feature - perhaps enough to say "hey, here are all the places we have run tests & seen the performance tradeoff is worthwhile for us (& possibly that it's close to the zero-init case, but that's sort of orthogonal, imho - that it's worthwhile is the main thing) - perhaps other folks would be willing to test it (non-zero init) & see if it's worthwhile to them - and if it isn't/they're interested in more performance, maybe all that evidence we can gain from the places where it's easy for us to rebuild compilers, etc, would make it interesting enough to motivate someone to do build the kernel with a custom compiler & do some performance measurements, etc... <br><br>Sorry that was a bit rambly, anyway.<br><br>- Dave<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div></div></div></div><div dir="ltr"><div class="gmail_quote"><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>We/Google do build the compiler from scratch, I assume we pick the configuration options we build with & some of them probably aren't the defaults for a release build of LLVM. So if it was important that Google's production compiler had these features enabled (rather than building a test compiler for running some experiments), that doesn't seem (at least to me, at this moment) especially prohibitive, is it?<br> </div></div></div>
</blockquote></div></div></blockquote></div></div>