<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 16, 2019, at 7:39 PM, Kostya Serebryany <<a href="mailto:kcc@google.com" class="">kcc@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div dir="ltr" class=""><br class=""></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 16, 2019 at 6:50 PM Peter Collingbourne <<a href="mailto:peter@pcc.me.uk" class="">peter@pcc.me.uk</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class=""><div dir="ltr" class="">On Wed, Jan 16, 2019 at 6:10 PM Kostya Serebryany via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a>> wrote:<br class=""></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class=""><div class=""><br class=""><br class=""></div><div class="">I’ve seen exactly the same problem, it’s definitely fixable but I haven’t tried to tackle it yet. Do you intend to do so? I’m more than happy to help with design / code / reviews. How do you want to proceed?</div></div></div></blockquote><div class=""><br class=""></div><div class="">We even started working on a related analysis pass, but got distracted. </div><div class=""><a href="https://reviews.llvm.org/D53336" target="_blank" class="">https://reviews.llvm.org/D53336</a><br class=""></div><div class=""><a href="https://reviews.llvm.org/D54541" target="_blank" class="">https://reviews.llvm.org/D54541</a><br class=""></div><div class="">I hope we can get back to it in a month or so, but can't promise. :( </div></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">I don't think you need LTO (or any type of sophisticated analysis at all) to eliminate the stores in this particular case. It seems that all that you need to do is make it the responsibility of the ctor to perform the initialization. We'd have to see how many stores this would actually eliminate in practice, though.</div></div></div></blockquote><div class=""><br class=""></div><div class="">So, we force every CTOR to fully initialize *this and make sure the callers of any CTOR know this. </div><div class="">That's an option. </div></div></div></div></blockquote><div><br class=""></div><div>I don’t think this is generally what we want: only considering ctors is too specific. I think we rather want a more general solution. Here are notes that Duncan and I wrote when initially investigating perf / size regressions (for Apple folks, see radar 43700567 and 43704706). I haven’t prototyped an implementation yet, I don’t think it’s too hard. I’ll get to it sometime this year, but I’m sharing my notes in case you can find someone who’s willing to do the work first.</div><div><br class=""></div><div><br class=""></div><div><b class=""># IPO should track pointer values which are written to, enabling DSO</b></div><div><br class=""></div><div><div>As part of variable-auto init we're creating more stack variable initializations. A common code pattern is the following:</div><div><br class=""></div></div></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div><div><div><font face="Courier" class="">int optimize_me() {</font></div></div></div><div><div><div><font face="Courier" class=""> int result;</font></div></div></div><div><div><div><font face="Courier" class=""> my_amazing_function(&result);</font></div></div></div><div><div><div><font face="Courier" class=""> // …</font></div></div></div><div><div><div><font face="Courier" class=""> return result;</font></div></div></div><div><div><div><font face="Courier" class="">}</font></div></div></div></blockquote><div><div><div><br class=""></div><div>With my change, we now initialize result because I have no idea whether <font face="Courier" class="">my_amazing_function</font> is truly amazing and will actually initialize result. This isn’t specific to stack variable initialization, it’s just aggravated by it. This example applies to C++ constructors as well.</div><div><br class=""></div><div>I propose an inter-procedural optimization to do something somewhat similar to <font face="Courier" class="">dereferenceable(<n>)</font> as described <a href="https://llvm.org/docs/LangRef.html#parameter-attributes" class="">here</a>.</div><div><br class=""></div><div>The ultimate goal is to identify dead stores in the caller.</div><div><br class=""></div><div>The algorithm would be as follows:</div><div><br class=""></div><div>For each function:</div><div> For each parameter:</div><div> If the parameter is a pointer:</div><div> Start at the entry point, assuming no bytes are written.</div><div> Traverse the control flow, and collect the intersection of bytes written through each diamond.</div><div> Tag the function with attribute <font face="Courier" class="">written(<M>)</font>, where M is the intersection of byte masks from all returns.</div><div><br class=""></div><div>Instead of a mask we could mimic dereferenceable and only track bytes [0, N], without holes.</div><div><br class=""></div><div>This analysis can always conservatively say that no bits are ever written.</div><div><br class=""></div><div>With this analysis in place, dead store elimination can then treat each call to a function tagged with <font face="Courier" class="">written(<M>)</font> as a store to the bytes in the mask. This will allow eliminating dead stores, of which there will be many more due to stack variable initialization. This will also allow eliminating dead stores to the heap.</div><div><br class=""></div><div>I haven’t thought about the impact this would have on invoke. I think it’s OK to ignore invoke for now, and only care about call.</div><div><br class=""></div><div><br class=""></div><div><b class=""># Frontend support for attribute to track pointer values that are written to</b></div><div><br class=""></div></div><div><div>We need additional frontend support for "IPO should track pointer values which are written to, enabling DSO”.</div><div><br class=""></div><div>In particular, in some cases, I suspect we can cheaply infer this attribute in IRGen. This would allow us to leverage it in places where IPO wouldn't be allowed to infer the attribute (e.g., <font face="Courier" class="">linkonce_odr</font>; see <a href="https://bugs.llvm.org/show_bug.cgi?id=26774" class="">this bug for why we can't</a>).</div><div><br class=""></div><div>We might also add a source-level Clang attribute, which Sema would reject (error out) if a simple CFG analysis cannot prove its correctness (error if it's invalid or "too hard to prove", similar to constexpr). This attribute would:</div><div>- document behaviour in the source, making it obvious in the API that it's safe to pass in uninitialized memory;</div><div>- suppress <font face="Courier" class="">-Wuninitialized</font> and <font face="Courier" class="">-Wmaybe-uninitialized</font> in the caller; and</div><div>- allow callers to optimize even if the callee definition is not available/in another TU.</div><div><br class=""></div><div>For the source-level attribute, we might want to support something simpler than a mask as detailed above—e.g., all-or-nothing, or listing struct fields instead of bit ranges.</div></div><div><br class=""></div><div><br class=""></div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class=""><div class="gmail_quote"><div class="">Peter</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div class="gmail_quote"><div class=""><br class=""></div><div class=""> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div class="">Compare to -ftrivial-auto-var-init<b class="">=zero</b>:</div><div class=""><br class=""></div><div class=""><div class=""><span style="white-space:pre-wrap" class=""> </span>xorps<span style="white-space:pre-wrap" class=""> </span>%xmm0, %xmm0</div><div class=""><span style="white-space:pre-wrap" class=""> </span>movaps<span style="white-space:pre-wrap" class=""> </span>%xmm0, 48(%rsp)</div><div class=""><span style="white-space:pre-wrap" class=""> </span>movaps<span style="white-space:pre-wrap" class=""> </span>%xmm0, 32(%rsp)</div><div class=""><span style="white-space:pre-wrap" class=""> </span>movaps<span style="white-space:pre-wrap" class=""> </span>%xmm0, 16(%rsp)</div><div class=""><span style="white-space:pre-wrap" class=""> </span>movaps<span style="white-space:pre-wrap" class=""> </span>%xmm0, (%rsp)</div><div class=""><span style="white-space:pre-wrap" class=""> </span>movq<span style="white-space:pre-wrap" class=""> </span>$0, 64(%rsp)</div></div><div class=""><br class=""></div><div class=""><div class=""><span style="white-space:pre-wrap" class=""> </span>movi<span style="white-space:pre-wrap" class=""> </span>v0.2d, #0000000000000000</div><div class=""><span style="white-space:pre-wrap" class=""> </span>mov<span style="white-space:pre-wrap" class=""> </span>x0, sp</div><div class=""><span style="white-space:pre-wrap" class=""> </span>str<span style="white-space:pre-wrap" class=""> </span>xzr, [sp, #64]</div><div class=""><span style="white-space:pre-wrap" class=""> </span>stp<span style="white-space:pre-wrap" class=""> </span>q0, q0, [sp, #32]</div><div class=""><span style="white-space:pre-wrap" class=""> </span>stp<span style="white-space:pre-wrap" class=""> </span>q0, q0, [sp]</div></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">OTOH, with a relatively simple LTO-based analysis we can get rid of these extra auto-inits completely. <br class=""></div><div class=""><br class=""></div><div class="">CC <a class="gmail_plusreply" id="gmail-m_2145673152025286586m_7615951652553076742gmail-m_4037661464340329545gmail-m_1072355842374943900plusReplyChip-5" href="mailto:vitalybuka@google.com" target="_blank">@Vitaly Buka</a> <a class="gmail_plusreply" id="gmail-m_2145673152025286586m_7615951652553076742gmail-m_4037661464340329545gmail-m_1072355842374943900plusReplyChip-6" href="mailto:pcc@google.com" target="_blank">@Peter Collingbourne</a> <a class="gmail_plusreply" id="gmail-m_2145673152025286586m_7615951652553076742gmail-m_4037661464340329545gmail-m_1072355842374943900plusReplyChip-7" href="mailto:eugenis@google.com" target="_blank">@Evgeniy Stepanov</a> </div></div></div></div></div></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">Why LTO? Are you observing this cross-TU? I think we want to first do same-TU, and then teach LTO about it too.</div></div></div></blockquote><div class=""><br class=""></div><div class="">For the analysis pass, it doesn't matter if it's same-TU or cross-TU -- it will use all information it sees. </div><div class="">So, it should work for same-TU even w/o LTO. </div><div class="">We see this either cross-TU or when a CTOR is marked as noinline. </div><div class=""><br class=""></div><div class=""> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class=""><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div class="">--kcc </div></div></div></div></div></div></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Tue, Dec 18, 2018 at 11:38 AM Kostya Serebryany <<a href="mailto:kcc@google.com" target="_blank" class="">kcc@google.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class="">2019 is going to have one bug class fewer. :) <div class="">(unless Jann&Co find new bug classes again)</div><div class=""><br class=""></div><div class="">Looking forward to the followup patches (e.g. padding gaps) </div><div class="">and to doing the measurements. </div><div class=""><br class=""></div><div class="">--kcc </div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Tue, Dec 18, 2018 at 10:53 AM JF Bastien <<a href="mailto:jfbastien@apple.com" target="_blank" class="">jfbastien@apple.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="">Hello fans of the pre-C++11 `auto` keyword!<div class=""><br class=""></div><div class="">Thanks to reviews from Peter and Richard, automatic variable initialization landed last night:</div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px" class=""><a href="https://reviews.llvm.org/rL349442" target="_blank" class="">https://reviews.llvm.org/rL349442</a></blockquote><div class=""><br class=""></div>Chandler pointed out that I should have circled back to the RFC in case any of the finer points needed tuning. Let me know if there’s any follow-up you’d like! I’ve made zero-init harder / uglier to use as was requested, while allowing folks like Kostya to test it out.<div class=""><br class=""></div><div class="">Let me know if you find bugs (in your code, or in the implementation), and please file bugs on any missed optimization opportunities. I know of a handful of missing optimizations which I intend to tackle in the near future. I’d also love to hear what kind of performance / size impact you see from various codebases. </div><div class=""><br class=""></div><div class="">As pointed out in the patch there’s a few other hardenings that I’ll want to tackle next. I’ll do so in the new year.</div><div class=""><br class=""></div><div class="">Thanks,</div><div class=""><br class=""></div><div class="">JF<br class=""><div class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Dec 11, 2018, at 3:18 PM, Joe Bialek via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a>> wrote:</div><br class="gmail-m_2145673152025286586m_7615951652553076742gmail-m_4037661464340329545gmail-m_1072355842374943900gmail-m_8814888969811067093gmail-m_4370604207350482532gmail-m_-4389096554537496804Apple-interchange-newline"><div class=""><div class="gmail-m_2145673152025286586m_7615951652553076742gmail-m_4037661464340329545gmail-m_1072355842374943900gmail-m_8814888969811067093gmail-m_4370604207350482532gmail-m_-4389096554537496804WordSection1" 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 style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">We went with zero initialization for production builds in Visual Studio because we anticipate zero being the fastest, smallest code gen, and safest value for the following cases:<u class=""></u><u class=""></u></div><ul type="disc" style="margin-bottom:0in;margin-top:0in" class=""><li class="gmail-m_2145673152025286586m_7615951652553076742gmail-m_4037661464340329545gmail-m_1072355842374943900gmail-m_8814888969811067093gmail-m_4370604207350482532gmail-m_-4389096554537496804MsoListParagraph" style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">Pointer: A non-zero pointer could potentially point at valid code. On Windows x64, the first 64kb of the virtual address space is guaranteed to not be mappable and the last 512GB of the virtual address space (today) has the space guarantee. So null pointer or near-null pointer dereferences are denial of service at worst.<u class=""></u><u class=""></u></li><li class="gmail-m_2145673152025286586m_7615951652553076742gmail-m_4037661464340329545gmail-m_1072355842374943900gmail-m_8814888969811067093gmail-m_4370604207350482532gmail-m_-4389096554537496804MsoListParagraph" style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">Size: If you forget to set a size as an out parameter we’d rather it’s set to 0 so you don’t index out of bounds.<u class=""></u><u class=""></u></li><li class="gmail-m_2145673152025286586m_7615951652553076742gmail-m_4037661464340329545gmail-m_1072355842374943900gmail-m_8814888969811067093gmail-m_4370604207350482532gmail-m_-4389096554537496804MsoListParagraph" style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">Index: Same as size.<u class=""></u><u class=""></u></li></ul><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">We are using this mitigation to downgrade vulnerabilities from remote code execution, elevation of privilege, or information disclosure, down to denial of service at worst.<u class=""></u><u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">Assuming the denial of service isn’t for a scenario where it matters (there are many types of DOS we don’t really worry about for security), we will not bother servicing the vulnerabilities down-level and instead only fix them for new code.<u class=""></u><u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">It is helpful for us to have deterministic behavior to help accomplish this goal. If an engineer knows a value is always set to 0, they can quickly determine if the bug report is actually exploitable or not. If it is initialized to a random or compile time constant value, we’ll need to do more work to determine if the bug is exploitable.<u class=""></u><u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">We are not zero initializing CHK builds to prevent folks from taking a dependency on this feature.<u class=""></u><u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">Joe<u class=""></u><u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><b class="">From:</b><span class="gmail-m_2145673152025286586m_7615951652553076742gmail-m_4037661464340329545gmail-m_1072355842374943900gmail-m_8814888969811067093gmail-m_4370604207350482532gmail-m_-4389096554537496804Apple-converted-space"> </span>Kostya Serebryany <<a href="mailto:kcc@google.com" target="_blank" class="">kcc@google.com</a>><span class="gmail-m_2145673152025286586m_7615951652553076742gmail-m_4037661464340329545gmail-m_1072355842374943900gmail-m_8814888969811067093gmail-m_4370604207350482532gmail-m_-4389096554537496804Apple-converted-space"> </span><br class=""><b class="">Sent:</b><span class="gmail-m_2145673152025286586m_7615951652553076742gmail-m_4037661464340329545gmail-m_1072355842374943900gmail-m_8814888969811067093gmail-m_4370604207350482532gmail-m_-4389096554537496804Apple-converted-space"> </span>Tuesday, December 11, 2018 3:04 PM<br class=""><b class="">To:</b><span class="gmail-m_2145673152025286586m_7615951652553076742gmail-m_4037661464340329545gmail-m_1072355842374943900gmail-m_8814888969811067093gmail-m_4370604207350482532gmail-m_-4389096554537496804Apple-converted-space"> </span>Mehdi AMINI <<a href="mailto:joker.eph@gmail.com" target="_blank" class="">joker.eph@gmail.com</a>>; Jann Horn <<a href="mailto:jannh@google.com" target="_blank" class="">jannh@google.com</a>><br class=""><b class="">Cc:</b><span class="gmail-m_2145673152025286586m_7615951652553076742gmail-m_4037661464340329545gmail-m_1072355842374943900gmail-m_8814888969811067093gmail-m_4370604207350482532gmail-m_-4389096554537496804Apple-converted-space"> </span>David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank" class="">dblaikie@gmail.com</a>>; Richard Smith <<a href="mailto:richard@metafoo.co.uk" target="_blank" class="">richard@metafoo.co.uk</a>>; Clang Dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a>>; Joe Bialek <<a href="mailto:jobialek@microsoft.com" target="_blank" class="">jobialek@microsoft.com</a>><br class=""><b class="">Subject:</b><span class="gmail-m_2145673152025286586m_7615951652553076742gmail-m_4037661464340329545gmail-m_1072355842374943900gmail-m_8814888969811067093gmail-m_4370604207350482532gmail-m_-4389096554537496804Apple-converted-space"> </span>Re: [cfe-dev] [RFC] automatic variable initialization<u class=""></u><u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">One more dimension in this discussion (zero-init vs pattern-init) is what will security get from those options.<u class=""></u><u class=""></u></div><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">My second-hand knowledge here suggests that zero-init may have *on average* better security guarantees than non-zero init.<u class=""></u><u class=""></u></div></div><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">For example if the uninitialized data is interpreted as a length of something, it better be zero than any large number or, worse, a negative signed number. <u class=""></u><u class=""></u></div></div><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><a href="mailto:jannh@google.com" style="color:purple;text-decoration:underline" target="_blank" class="">+Jann Horn</a> and Joe Bialek who have first-hand knowledge here. <u class=""></u><u class=""></u></div></div><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div></div><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">--kcc <u class=""></u><u class=""></u></div></div><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div></div><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""> <u class=""></u><u class=""></u></div><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div></div></div></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div><div class=""><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">On Thu, Dec 6, 2018 at 3:58 PM Kostya Serebryany <<a href="mailto:kcc@google.com" style="color:purple;text-decoration:underline" target="_blank" class="">kcc@google.com</a>> wrote:<u class=""></u><u class=""></u></div></div><blockquote style="border-style:none none none solid;border-left-width:1pt;border-left-color:rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in" class=""><div class=""><p class="MsoNormal" style="margin:0in 0in 12pt;font-size:11pt;font-family:Calibri,sans-serif"><u class=""></u> <u class=""></u></p><div class=""><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">On Thu, Dec 6, 2018 at 3:55 PM Mehdi AMINI <<a href="mailto:joker.eph@gmail.com" style="color:purple;text-decoration:underline" target="_blank" class="">joker.eph@gmail.com</a>> wrote:<u class=""></u><u class=""></u></div></div><blockquote style="border-style:none none none solid;border-left-width:1pt;border-left-color:rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in" class=""><div class=""><p class="MsoNormal" style="margin:0in 0in 12pt;font-size:11pt;font-family:Calibri,sans-serif"><u class=""></u> <u class=""></u></p><div class=""><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">On Thu, Dec 6, 2018 at 3:43 PM Kostya Serebryany <<a href="mailto:kcc@google.com" style="color:purple;text-decoration:underline" target="_blank" class="">kcc@google.com</a>> wrote:<u class=""></u><u class=""></u></div></div><blockquote style="border-style:none none none solid;border-left-width:1pt;border-left-color:rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in" class=""><div class=""><p class="MsoNormal" style="margin:0in 0in 12pt;font-size:11pt;font-family:Calibri,sans-serif"><u class=""></u> <u class=""></u></p><div class=""><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">On Thu, Dec 6, 2018 at 3:03 PM Mehdi AMINI <<a href="mailto:joker.eph@gmail.com" style="color:purple;text-decoration:underline" target="_blank" class="">joker.eph@gmail.com</a>> wrote:<u class=""></u><u class=""></u></div></div><blockquote style="border-style:none none none solid;border-left-width:1pt;border-left-color:rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in" class=""><div class=""><p class="MsoNormal" style="margin:0in 0in 12pt;font-size:11pt;font-family:Calibri,sans-serif"><u class=""></u> <u class=""></u></p><div class=""><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">On Thu, Dec 6, 2018 at 1:01 PM Kostya Serebryany <<a href="mailto:kcc@google.com" style="color:purple;text-decoration:underline" target="_blank" class="">kcc@google.com</a>> wrote:<u class=""></u><u class=""></u></div></div><blockquote style="border-style:none none none solid;border-left-width:1pt;border-left-color:rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in" class=""><div class=""><p class="MsoNormal" style="margin:0in 0in 12pt;font-size:11pt;font-family:Calibri,sans-serif"><u class=""></u> <u class=""></u></p><div class=""><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">On Wed, Dec 5, 2018 at 6:07 PM Mehdi AMINI via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" style="color:purple;text-decoration:underline" target="_blank" class="">cfe-dev@lists.llvm.org</a>> wrote:<u class=""></u><u class=""></u></div></div><blockquote style="border-style:none none none solid;border-left-width:1pt;border-left-color:rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in" class=""><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">I have the same question as David: I don't understand why this isn't just an experimental build option disabled by default? (Google, Apple, etc. can just enable it in their build script, no need to patch the source).<u class=""></u><u class=""></u></div></div></blockquote><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div></div><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">I will need to rebuild half a dozen compiler binaries to do the measurements I need.<u class=""></u><u class=""></u></div></div><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">This is going to double the cost of the effort for me because it adds too many extra moving pieces. <u class=""></u><u class=""></u></div></div></div></div></blockquote><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div></div><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">Not sure I follow, you have to build the compiler anyway to get it after the code is patched?<u class=""></u><u class=""></u></div></div><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">The only thing you would have to do is one CL to enable the build flag (that expose the command line flag) inside your codebase and then you get your toolchain as usual?<u class=""></u><u class=""></u></div></div></div></div></blockquote><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div></div><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">Once the JF's patch is in, I'll have it in most production compilers I care about in 2-6 weeks, w/o any effort on my side. <u class=""></u><u class=""></u></div></div><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">None of those builders (easily) support adding custom patches, and even a build flag is going to be very non-trivial. <u class=""></u><u class=""></u></div></div><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">I can deal with one or two of those builds relatively easily, but not with the rest. <u class=""></u><u class=""></u></div></div></div></div></blockquote><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div></div><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">What builders are you referring to? So far I was assuming we were talking about your internal infrastructure that produces your production compilers.<u class=""></u><u class=""></u></div></div></div></div></blockquote><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div></div><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">I am talking about our internal infra. <u class=""></u><u class=""></u></div></div><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">But we have multiple independent builders from multiple independent compiler users (e.g. Chrome and Android are using different compiler builds). <u class=""></u><u class=""></u></div></div><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""> <u class=""></u><u class=""></u></div></div><blockquote style="border-style:none none none solid;border-left-width:1pt;border-left-color:rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in" class=""><div class=""><div class=""><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div></div><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""> <u class=""></u><u class=""></u></div></div><blockquote style="border-style:none none none solid;border-left-width:1pt;border-left-color:rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in" class=""><div class=""><div class=""><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div></div><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""> <u class=""></u><u class=""></u></div></div><blockquote style="border-style:none none none solid;border-left-width:1pt;border-left-color:rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in" class=""><div class=""><div class=""><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div></div><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">-- <u class=""></u><u class=""></u></div></div><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">Mehdi<u class=""></u><u class=""></u></div></div><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div></div><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div></div><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""> <u class=""></u><u class=""></u></div></div><blockquote style="border-style:none none none solid;border-left-width:1pt;border-left-color:rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in" class=""><div class=""><div class=""><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""> <u class=""></u><u class=""></u></div></div><blockquote style="border-style:none none none solid;border-left-width:1pt;border-left-color:rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in" class=""><div class=""><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">The only argument I read in the thread was about allowing people to make performance measurement without rebuilding the compiler, but I have a hard time reconciliation this with the fact that we're talking about not shipping this before performing the actual measurements?<u class=""></u><u class=""></u></div></div><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div></div><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">I expect that anyone that cares enough about the perf impact of this to influence the development of the feature in clang should already be rebuilding their compiler today. <u class=""></u><u class=""></u></div></div><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div></div><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">-- <u class=""></u><u class=""></u></div></div><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">Mehdi<u class=""></u><u class=""></u></div></div><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div></div></div></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div><div class=""><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">On Mon, Dec 3, 2018 at 5:58 PM David Blaikie via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" style="color:purple;text-decoration:underline" target="_blank" class="">cfe-dev@lists.llvm.org</a>> wrote:<u class=""></u><u class=""></u></div></div><blockquote style="border-style:none none none solid;border-left-width:1pt;border-left-color:rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in" class=""><div class=""><p class="MsoNormal" style="margin:0in 0in 12pt;font-size:11pt;font-family:Calibri,sans-serif">Just out of curiosity - what's the major difference between a build-time off-by-default feature and a build-time on-by-default-but-off-in-release branches feature? If we're only targeting groups that build/release the compiler themselves, then they're likely able to opt-in to a build-time feature easily enough, I'd think? & then there's no need to make our releases different from day-to-day builds?<br class=""><br class="">But sounds like folks are in general agreement of a way forward, so I don't want to disrupt/delay that.<u class=""></u><u class=""></u></p><div class=""><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">On Wed, Nov 28, 2018 at 11:14 PM Chandler Carruth <<a href="mailto:chandlerc@gmail.com" style="color:purple;text-decoration:underline" target="_blank" class="">chandlerc@gmail.com</a>> wrote:<u class=""></u><u class=""></u></div></div><blockquote style="border-style:none none none solid;border-left-width:1pt;border-left-color:rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in" class=""><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">Suggested compromise technique to at least get an initial set of numbers:<u class=""></u><u class=""></u></div><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div></div><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">1) Require a special, long, ugly flag name.<u class=""></u><u class=""></u></div></div><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">2) Make it a CC1 flag, requiring -Xclang ... to use.<u class=""></u><u class=""></u></div></div><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">3) Emit a warning by default (that cannot be suppressed with a -Wno-... flag) when this flag is enabled.<u class=""></u><u class=""></u></div></div><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">4) Commit to never including this flag in any upstream release. Either we remove it before the next release branches or we revert it on the branch.<u class=""></u><u class=""></u></div></div><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div></div><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">Most of the folks we're hoping to get performance data with are willing to use a not-yet-released build of Clang. They won't have to actually patch it in any way. They will have strong reminders to not deploy this in any way due to the warning.<u class=""></u><u class=""></u></div></div><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div></div><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">Thoughts?<u class=""></u><u class=""></u></div></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div></div><div class=""><div class=""><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">On Wed, Nov 28, 2018 at 4:34 PM Kostya Serebryany via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" style="color:purple;text-decoration:underline" target="_blank" class="">cfe-dev@lists.llvm.org</a>> wrote:<u class=""></u><u class=""></u></div></div></div></div><div class=""><div class=""><blockquote style="border-style:none none none solid;border-left-width:1pt;border-left-color:rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in" class=""><div class=""><div class=""><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">On Wed, Nov 28, 2018 at 3:28 PM David Blaikie <<a href="mailto:dblaikie@gmail.com" style="color:purple;text-decoration:underline" target="_blank" class="">dblaikie@gmail.com</a>> wrote:<u class=""></u><u class=""></u></div></div><blockquote style="border-style:none none none solid;border-left-width:1pt;border-left-color:rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in" class=""><div class=""><p class="MsoNormal" style="margin:0in 0in 12pt;font-size:11pt;font-family:Calibri,sans-serif"><u class=""></u> <u class=""></u></p><div class=""><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">On Wed, Nov 28, 2018 at 3:17 PM Kostya Serebryany <<a href="mailto:kcc@google.com" style="color:purple;text-decoration:underline" target="_blank" class="">kcc@google.com</a>> wrote:<u class=""></u><u class=""></u></div></div><blockquote style="border-style:none none none solid;border-left-width:1pt;border-left-color:rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in" class=""><div class=""><div class=""><blockquote style="border-style:none none none solid;border-left-width:1pt;border-left-color:rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in" class=""><div class=""><div class=""><blockquote style="border-style:none none none solid;border-left-width:1pt;border-left-color:rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in" class=""><div class=""><div class=""><blockquote style="border-style:none none none solid;border-left-width:1pt;border-left-color:rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in" class=""><div class=""><div class=""><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><br class="">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.<u class=""></u><u class=""></u></div></div></div></div></blockquote><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div></div></div></div><div class=""><div class=""><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">This approach will significantly impair my ability to do the measurements I need. <u class=""></u><u class=""></u></div></div></div></div></blockquote><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><br class="">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 class=""><br class="">Specifically for Google though - would it be that difficult for Google to opt-in to a certain build configuration of LLVM?<u class=""></u><u class=""></u></div></div></div></div></blockquote><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div></div></div></div><div class=""><div class=""><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">Absolutely yes. <u class=""></u><u class=""></u></div></div><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">Google is not just a single <a href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdelivery.acm.org%2F10.1145%2F2860000%2F2854146%2Fp78-potvin.pdf%3Fip%3D104.133.8.94%26id%3D2854146%26acc%3DOA%26key%3D4D4702B0C3E38B35%252E4D4702B0C3E38B35%252E4D4702B0C3E38B35%252E5945DC2EABF3343C%26__acm__%3D1543446999_3aadcd36f657e2297430c38bee93f16c&data=02%7C01%7Cjobialek%40microsoft.com%7C533e0fe1444d4b5a3a6b08d65fbcf479%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636801662510848537&sdata=dd4I1xQ5qfawzLwsnBM3iqsypqZ%2BlFswj5IgKa%2FLHbw%3D&reserved=0" style="color:purple;text-decoration:underline" target="_blank" class="">monolithic code base</a>. <u class=""></u><u class=""></u></div></div></div></div></blockquote><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><br class="">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 class=""> <u class=""></u><u class=""></u></div></div><blockquote style="border-style:none none none solid;border-left-width:1pt;border-left-color:rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in" class=""><div class=""><div class=""><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">Besides that monolithic thing, we have Android, Chrome, ChromeOS, Fuchsia, and a bazillion of smaller efforts that use their own toolchains. <u class=""></u><u class=""></u></div></div></div></div></blockquote><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><br class="">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 class=""> <u class=""></u><u class=""></u></div></div><blockquote style="border-style:none none none solid;border-left-width:1pt;border-left-color:rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in" class=""><div class=""><div class=""><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">In some cases the most reliable and complete way of measuring performance changes is to submit the changes to revision control, <u class=""></u><u class=""></u></div></div><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">and let the performance bots shew it for a couple of days. That's how we iterated with the LLVM's CFI in Chrome. <u class=""></u><u class=""></u></div></div><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">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. <u class=""></u><u class=""></u></div></div></div></div></blockquote><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><br class="">Yeah, I can imagine that one's a bit trickier - how's performance evaluation of the kernel done?<u class=""></u><u class=""></u></div></div></div></div></blockquote><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div></div></div></div><div class=""><div class=""><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">I don't think anyone knows that. :-|<u class=""></u><u class=""></u></div></div><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">And requiring a compiler patch will shift the problem from "hard" to "I'd better do something else". <u class=""></u><u class=""></u></div></div></div></div><div class=""><div class=""><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""> <u class=""></u><u class=""></u></div></div><blockquote style="border-style:none none none solid;border-left-width:1pt;border-left-color:rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in" class=""><div class=""><div class=""><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">(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 class=""><br class="">Sorry that was a bit rambly, anyway.<br class=""><br class="">- Dave<br class=""> <u class=""></u><u class=""></u></div></div><blockquote style="border-style:none none none solid;border-left-width:1pt;border-left-color:rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in" class=""><div class=""><div class=""><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div></div><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div></div><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""> <u class=""></u><u class=""></u></div></div><blockquote style="border-style:none none none solid;border-left-width:1pt;border-left-color:rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in" class=""><div class=""><div class=""><div class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">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 class=""> <u class=""></u><u class=""></u></div></div></div></div></blockquote></div></div></blockquote></div></div></blockquote></div></div></blockquote></div></div><div class=""><div class=""><blockquote style="border-style:none none none solid;border-left-width:1pt;border-left-color:rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in" class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">_______________________________________________<u class=""></u><u class=""></u></div></blockquote></div></div><div class=""><div class=""><blockquote style="border-style:none none none solid;border-left-width:1pt;border-left-color:rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in" class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><br class="">cfe-dev mailing list<br class=""><a href="mailto:cfe-dev@lists.llvm.org" style="color:purple;text-decoration:underline" target="_blank" class="">cfe-dev@lists.llvm.org</a><br class=""><a href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.llvm.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fcfe-dev&data=02%7C01%7Cjobialek%40microsoft.com%7C533e0fe1444d4b5a3a6b08d65fbcf479%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636801662510858549&sdata=J1qIBl35xJOU4LXt2pmJKrl7Jo3RzuG04e7mWmXdULo%3D&reserved=0" style="color:purple;text-decoration:underline" target="_blank" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><u class=""></u><u class=""></u></div></blockquote></div></div></blockquote></div></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">_______________________________________________<br class="">cfe-dev mailing list<br class=""><a href="mailto:cfe-dev@lists.llvm.org" style="color:purple;text-decoration:underline" target="_blank" class="">cfe-dev@lists.llvm.org</a><br class=""><a href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.llvm.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fcfe-dev&data=02%7C01%7Cjobialek%40microsoft.com%7C533e0fe1444d4b5a3a6b08d65fbcf479%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636801662510868553&sdata=wC0zWaGYC6YVWA3W7X3PEUjbePjhZdOoKVy5vzD6y2I%3D&reserved=0" style="color:purple;text-decoration:underline" target="_blank" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><u class=""></u><u class=""></u></div></blockquote></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">_______________________________________________<br class="">cfe-dev mailing list<br class=""><a href="mailto:cfe-dev@lists.llvm.org" style="color:purple;text-decoration:underline" target="_blank" class="">cfe-dev@lists.llvm.org</a><br class=""><a href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.llvm.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fcfe-dev&data=02%7C01%7Cjobialek%40microsoft.com%7C533e0fe1444d4b5a3a6b08d65fbcf479%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636801662510868553&sdata=wC0zWaGYC6YVWA3W7X3PEUjbePjhZdOoKVy5vzD6y2I%3D&reserved=0" style="color:purple;text-decoration:underline" target="_blank" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><u class=""></u><u class=""></u></div></blockquote></div></div></blockquote></div></div></blockquote></div></div></blockquote></div></div></blockquote></div></div></blockquote></div></div><span 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;float:none;display:inline" class="">_______________________________________________</span><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;text-decoration:none" class=""><span 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;float:none;display:inline" class="">cfe-dev mailing list</span><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;text-decoration:none" class=""><span 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;float:none;display:inline" class=""><a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a></span><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;text-decoration:none" class=""><span 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;float:none;display:inline" class=""><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" target="_blank" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a></span></div></blockquote></div><br class=""></div></div></div></blockquote></div>
</blockquote></div>
</div></blockquote></div><br class=""></div></blockquote></div></div></div></div>
_______________________________________________<br class="">
cfe-dev mailing list<br class="">
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a><br class="">
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br class="">
</blockquote></div><br clear="all" class=""><div class=""><br class=""></div>-- <br class=""><div dir="ltr" class="gmail-m_2145673152025286586m_7615951652553076742gmail_signature"><div dir="ltr" class="">-- <div class="">Peter</div></div></div></div>
</blockquote></div></div>
</div></blockquote></div><br class=""></body></html>