<div dir="ltr"><div dir="ltr">On Tue, Nov 27, 2018 at 5:56 PM Peter Collingbourne via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br><div class="gmail_quote"><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 dir="ltr">On Tue, Nov 27, 2018 at 2:34 PM JF Bastien <<a href="mailto:jfbastien@apple.com" target="_blank">jfbastien@apple.com</a>> wrote:<div class="gmail_quote"><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;line-break:after-white-space"><div><blockquote type="cite"><div>On Nov 27, 2018, at 2:14 PM, Peter Collingbourne <<a href="mailto:peter@pcc.me.uk" target="_blank">peter@pcc.me.uk</a>> wrote:</div><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;text-decoration:none"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Nov 27, 2018 at 1:50 PM JF Bastien via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:</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><div><blockquote type="cite"><div>On Nov 27, 2018, at 10:16 AM, David Blaikie via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:</div><div><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, Nov 26, 2018 at 6:55 PM Reid Kleckner <<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</a>> wrote:<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 dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, Nov 26, 2018 at 6:43 PM Kostya Serebryany via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<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 dir="ltr"><div class="gmail_quote"><div dir="ltr">On Sat, Nov 17, 2018 at 9:00 AM David Blaikie via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<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 dir="ltr">Would it be that drastic to have this require a code change/compiler rebuild to enable? It could be designed so the change is small/easy (changing a constant) but that the default compilers we all ship around (& especially not the official releases) don't allow access to this functionality.<br><br>Anyone wanting to gather data would have to make this small change, rebuild their compiler, build their target with this feature & gatehr results from there.</div></blockquote><div><br></div><div>This will cripple our ability to do measurements because in many cases we can only build things with whatever is the production compiler. </div><div>I'd rather just rename the flag to something like  -ftrivial-auto-var-init=zero-SCARY-WARNING-ABOUT-VOID-WARRANTY-GOES-HERE</div></div></div></blockquote></div></div></blockquote></div></div></div></blockquote></div><div>[...] Can we purposefully change the name of the zero-init flag / attribute on every release, until we finally remove it? Or is the only option to give up on 2. And add friction when trying to collect data?</div></div></blockquote><div><br></div><div>We can perhaps take inspiration from how the web platform introduces new experimental features. Historically this was done using vendor prefixes, but this didn't prevent people from using them (i.e. your 4). The approach that Blink (and I believe other vendors) has taken is to put these features behind a user configurable "enable experimental web platform features” setting. [...]</div></div></div></div></div></blockquote></div><div>Experimental features for web stuff is often enabled through e.g. <a>about:flags</a> or something similar (such as a command flag), you don’t rebuild your browser. [...]</div></div></blockquote></div><div><br></div>Yes it requires a rebuild but that's probably an order of magnitude more straightforward than requiring code changes. Although it's not exactly the same as web platform the basic idea is the same: enabling the feature is split up into two steps, where typically in "production" scenarios different entities are in control of the different steps. In the web platform case it's the web developer and the browser user and in our case it's the toolchain builder and the project maintainer.</div></blockquote><div><br></div><div>That analogy doesn't make sense to me. In the web-platform case, if I want to, let's say, disable Javascript, I don't rebuild my browser. I just click the "Disable Javascript" button. (Of course, the browser author has no particular reason to be scared that users might be running around with Javascript disabled — it's none of his business. Personally, I think the compiler dev <i>should</i> be equally not-scared at the prospect of users running around with this undefined behavior disabled — it's none of his business. But I admit that that <i>is</i> where the analogy to browsers breaks down.)</div><div><br></div><div>I have worked for many (smallish) places, and none of them have ever built their own Clang from source. That's just not something people do. They compile <i>their own</i> C++ codebase, yes; but they leave the compiling-of-the-compiler to the compiler devs. So any solution involving "let's just make everyone build their own Clang from source" is going to be a non-starter for the target audience (which, as I understand it, is people with large buggy codebases who want to quickly benchmark the difference between pattern-initialization and zero-initialization to convince themselves that pattern-initialization is no more expensive than zero-initialization, before going ahead and using pattern-initialization).</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 dir="ltr"> I guess if it's gated on an environment variable it's still possible for a project to enable the feature on its own by using "env" in its build commands.</div></blockquote><div><br></div><div>How about a <i>combination</i> of scary environment variable and scary command-line flag?</div><div>How about changing the spelling of the scary command-line flag on every release?</div><div><br></div><div>I was going to suggest something like "make the spelling of the command-line flag depend on the date and/or compiler binary itself, so you have to `clang --what-is-todays-scary-spelling` and use that." But that would break distributed builds.</div><div>I was going to suggest something like "error out unless the translation unit contains a #pragma with a scary name opting in to the behavior." But that would involve the user making code changes to their codebase, which is a non-starter.</div><div><br></div><div>Personally, I think "scary command-line flag" is exactly the right level of paranoia for this feature.</div><div>    "-Xclang -ftrivial-auto-var-init=FOR-INTERNAL-BENCHMARKING-ONLY"</div><div>Or smuggle it in under the guise of genericity:</div><div>    "-ftrivial-auto-var-init=pattern -Xclang -ftrivial-auto-var-init-pattern=00000000".</div><div><br></div><div>my $.02,</div><div>–Arthur</div></div></div></div>