<div dir="ltr"><br><br><div class="gmail_quote"><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:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><br><div><br><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><br class="m_8061569398135063963m_-1811421359608029238Apple-interchange-newline"><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"><br><br><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:<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><br><div><br><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><br class="m_8061569398135063963m_-1811421359608029238gmail-m_-1209052686766441166Apple-interchange-newline"><div><div dir="ltr"><br><br><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><br></div></div></div><div dir="ltr"><div class="gmail_quote"><div>Reminds me of -fheinous-gnu-extensions. ;-)</div></div></div></blockquote><div><br>Pretty much - and I don't think any choice of spelling is bad enough that it'd make it substantially less likely that people would end up depending on the behavior in their non-buggy codepaths. Once the flag is written into someone's build system, there it is... even if it's absurdly long/verbose/angry/whatever, generally it'll slip under the radar after it's written into the build system.<br></div></div></div></div></blockquote></div><br><div>I’d like to get us to a point where we all agree to a solution. I think these statements are true:</div><div><br></div><div>0. We want to minimize the size / perf hit because that’ll maximize adoption.</div><div>1. We need to gather size / perf data of uninit versus zero-init versus pattern-init.</div><div>2. The easier it is to gather data, the faster it’ll be to find and address regressions we don’t know about (likely in other people’s codebases).</div><div>3. We don’t want to have zero-init long term, and we don’t want people to rely on it.</div><div>4. Giving the flag / attribute an ugly name won’t prevent people from using them.</div><div><br></div><div>These seem at odds because we don’t usually remove flags. 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. The closest analog to the setting for us would probably be a cmake build setting. This makes it easy for folks to collect data with the feature (no code changes, just reconfigure and rebuild), while making it impossible for an arbitrary project to start relying on the flag (unless they ship their own copy of clang, but then again that copy of clang could be modified in arbitrary ways as well).</div></div></div></div></div></blockquote><br></div><div>That still requires a rebuild of clang, right? 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. Something closer for us is a command-line flag, we could also require an environment variable with the command-line flag...</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. 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><br></div><div>Thanks,<div>-- <br><div dir="ltr" class="m_8061569398135063963gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">-- <div>Peter</div></div></div></div></div></div>