
<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="">Thanks to all a better fix landed on both trunk and LLVM 6.0!<div class=""><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Feb 16, 2018, at 11:37 AM, Teresa Johnson <<a href="mailto:tejohnson@google.com" class="">tejohnson@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><br class="Apple-interchange-newline"><br style="caret-color: rgb(0, 0, 0); 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; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><div class="gmail_quote" style="caret-color: rgb(0, 0, 0); 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; -webkit-text-stroke-width: 0px; text-decoration: none;">On Fri, Feb 16, 2018 at 8:26 AM, Mehdi AMINI<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:joker.eph@gmail.com" target="_blank" class="">joker.eph@gmail.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><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" class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote"><div class=""><div class="h5">2018-02-13 17:46 GMT-08:00 Mehdi AMINI<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:joker.eph@gmail.com" target="_blank" class="">joker.eph@gmail.com</a>></span>:<br class=""><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" class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote"><div class=""><div class="m_-8627109242900279217gmail-h5">2018-02-13 13:29 GMT-08:00 Quentin Colombet<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:qcolombet@apple.com" target="_blank" class="">qcolombet@apple.com</a>></span>:<br class=""><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;" class=""><div class="">Hi Mehdi,</div><br class=""><div class=""><br class=""><blockquote type="cite" class=""><span class="m_-8627109242900279217gmail-m_2867746353710724053gmail-"><div class="">On Feb 13, 2018, at 12:34 PM, Mehdi AMINI <<a href="mailto:joker.eph@gmail.com" target="_blank" class="">joker.eph@gmail.com</a>> wrote:</div><br class="m_-8627109242900279217gmail-m_2867746353710724053gmail-m_-7084138298041638735Apple-interchange-newline"></span><div class=""><div class="m_-8627109242900279217gmail-m_2867746353710724053gmail-h5"><div class=""><br class="m_-8627109242900279217gmail-m_2867746353710724053gmail-m_-7084138298041638735Apple-interchange-newline"><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=""><div class="gmail_quote" 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;">2018-02-08 17:34 GMT-08:00 Quentin Colombet via llvm-dev<span class="m_-8627109242900279217gmail-m_2867746353710724053gmail-m_-7084138298041638735Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.<wbr class="">org</a>></span>:<br class=""><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;" class="">Hi,<div class=""><br class=""></div><div class="">TL;DR</div><div class="">r317488 changed the way fast math flags are laid out in the bitcode and anyone compiling a pre-llvm-6.0 bitcode with llvm-6.0 will lose all the optimizations guarded by isFast and a pre-llvm-6.0 compiler compiling a llvm-6.0 bitcode will potentially generate incorrect code w.r.t. fast math expectations.</div><div class=""><br class=""></div><div class="">Should we bump the bitcode version because of that and have the autoupgrader properly rewrite the fast-math to preserve that semantic?</div><div class="">(I believe we should!)</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">* Context *</div><div class=""><br class=""></div><div class="">With <a href="https://reviews.llvm.org/D39304" target="_blank" class="">https://reviews.llvm.org/<wbr class="">D39304</a> / r317488 we got rid of the umbrella UnsafeMath flag and introduced 3 more flags that better represent the different things that happen under fast-math.</div><div class=""><br class=""></div><div class="">From a bitcode perspective, this change looks like this:</div><div class="">Before r317488 we had 6 bits that respectively represented:</div><div class=""><br class=""></div><div class="">UnsafeMath</div><div class="">nnan</div><div class="">ninf</div><div class="">nsz</div><div class="">arcp</div><div class="">contract</div><div class="">*unset*</div><div class=""><br class=""></div><div class="">(The order may not match what is exactly in the bitcode.)</div><div class=""><br class=""></div><div class=""><div class="">After r317488 we had 7 bits that respectively represented:</div></div><div class=""><div class="">reassoc (-UnsafeMath- is gone)</div><div class="">nnan</div><div class="">ninf</div><div class="">nsz</div><div class="">arcp</div><div class="">contract</div></div><div class="">*afn* (new bit)</div><div class=""><br class=""></div><div class="">Before r317488, fast-math was true if UnsafeMath was true (this should also imply all the other flags are sets). After r317488, fast-math is true if all the bits are set, in particular the afn, new one, too.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">* Problem *</div><div class=""><br class=""></div><div class="">Given we currently have no way to check if a bitcode file has been generated pre-r317488 or post-r317488 that means that:</div><div class="">1. a post-r317488 compiler is going to skip any optimization guarded by isFast for all pre-r317488 bitcode file (remember the afn bit is not set here)</div><div class="">2. a pre-r317488 compiler is going to run any optimization guarded by unsafeAlgebra for any post-r317488 bitcode file that has the reassoc bit (remember we repurposed UnsafeMath)</div><div class=""><br class=""></div><div class="">Scenario #2 might be unlikely but we’re potentially breaking the semantic of the program. It is particularly dangerous because there is nothing that is going to tell us that we are in this situation “downgrade" situation.</div><div class="">#1 means that any code that uses unsafeMath is going to get a performance hit.</div><div class=""><br class=""></div><div class="">In other words, one scenario implies generating wrong code and the other, runtime performance regressions.</div></div></blockquote><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div class="">Scenario #1 is unsupported AFAIK, unless I missed something the bitcode is not forward compatible: loading newer bitcode with an older LLVM has never been supported as far I can remember. </div></div></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">I agree, but we cannot detect that this is the situation we are in and debugging would prove hard. That said, if we say we don’t care, so be it :).</div></div></div></blockquote><div class=""><br class=""></div></div></div><div class="">I just mean that in general many things can blow up when the bitcode evolves, and we don't expect or support (as far as I know) llvm-3.9 to be used to read/process bitcode from llvm-4.0 for instance.</div><div class="">(I remember implementing in the Apple LLVM a hard check and failure for this: we don't even try)</div><span class="m_-8627109242900279217gmail-"><div class=""><br class=""></div><div class=""> </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 style="word-wrap: break-word; line-break: after-white-space;" class=""><div class=""><span class="m_-8627109242900279217gmail-m_2867746353710724053gmail-"><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_quote" 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 class=""><div class=""><br class=""></div><div class="">Scenario #2 is very much like other performance regression when we drop old metadata (i.e. bitcode upgrade isn't performance proof in general but only "best effort", there have been multiple instance of this in the past).</div></div></div></div></blockquote><blockquote type="cite" class=""><div class=""><div class="gmail_quote" 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 class=""><div class=""><br class=""></div><div class="">Usually IIRC we try not to version the bitcode at all this way (i.e. bitcode does not have a linear versioning that is regularly bumped) but instead make sure the encoding itself allows an easy upgrade. I.e. the encoding of the FMF should have been such that the reader can detect and upgrade to the new IR representation. </div><div class="">Now this is too late here I guess, so bumping may be a possible trade-off.</div></div></div></div></blockquote><div class=""><br class=""></div></span><div class="">Do you think we should do it, or live with the performance drop?</div></div></div></blockquote><div class=""><br class=""></div></span><div class="">I'm not saying this shouldn't be done, I don't have a dog in this fight: I was just providing another data point "as a matter of general policy" in the past there have been other cases where we haven't been able (or rather chose to not put effort) into preserving all the performance when upgrading (I think TBAA comes to my mind right now, but other kind of metadata have also been lost). Now every case is different, and the FMF can be considered too important to be left on the table.</div><div class="">For example it would impact LTO when loading libraries built with Xcode9 and before whenever the next released post-r317488 come up.</div><span class="m_-8627109242900279217gmail-"><div class=""><br class=""></div><div class=""> </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 style="word-wrap: break-word; line-break: after-white-space;" class=""><div class=""><div class="">I know this performance drop is not acceptable for our use cases, but I don’t want to impose our ruling on this.</div><span class="m_-8627109242900279217gmail-m_2867746353710724053gmail-"><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_quote" 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 class=""><div class="">What about any bitcode shipped after r317488 but before the version bump? Not worth taking into account because of the short period of time?</div></div></div></div></blockquote><div class=""><br class=""></div></span><div class="">I was hoping we can ignore that period of time because it was not in any official LLVM release.</div></div></div></blockquote></span></div></div></div></blockquote><div class=""><br class=""></div></div></div><div class="">Need to at least make sure everyone knows what to expect, so the cherry-pick for the LLVM 6.0 release should include an entry in the Release Notes.</div><div class=""><br class=""></div><div class="">Hans: this can only happen if you're still OK to cherry-pick in LLVM 6.0 branch<span class="Apple-converted-space"> </span><a href="https://reviews.llvm.org/D43253" target="_blank" class="">https://reviews.llvm.org/<wbr class="">D43253</a><br class=""></div><div class=""><br class=""></div><div class="">Duncan, Steven, Peter, Teresa: this change can break LTO if we read back bitcode emitted from trunk since r317488 (last November), any concerns?</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">For our usage of ThinLTO, we don't reuse bitcode across different revisions, so it wouldn't cause an issue. The LTO caching in lib/LTO/LTO.cpp also encodes the llvm revision, so it shouldn't be an issue there either.</div><div class=""><br class=""></div><div class="">Teresa</div><div class=""><br class=""></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" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><div class="">Best,</div><span class="HOEnZb"><font color="#888888" class=""><div class=""><br class=""></div><div class="">-- </div><div class="">Mehdi</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div></font></span></div></div></div></blockquote></div><br style="caret-color: rgb(0, 0, 0); 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; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><br clear="all" style="caret-color: rgb(0, 0, 0); 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; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><div style="caret-color: rgb(0, 0, 0); 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; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><br class=""></div><span style="caret-color: rgb(0, 0, 0); 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; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">--<span class="Apple-converted-space"> </span></span><br style="caret-color: rgb(0, 0, 0); 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; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><div class="gmail_signature" data-smartmail="gmail_signature" style="caret-color: rgb(0, 0, 0); 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; -webkit-text-stroke-width: 0px; text-decoration: none;"><span style="font-family: Times; font-size: inherit;" class=""><table cellspacing="0" cellpadding="0" class=""><tbody class=""><tr style="color: rgb(85, 85, 85); font-family: sans-serif; font-size: small;" class=""><td nowrap="" style="border-top-style: solid; border-top-color: rgb(213, 15, 37); border-top-width: 2px;" class="">Teresa Johnson |</td><td nowrap="" style="border-top-style: solid; border-top-color: rgb(51, 105, 232); border-top-width: 2px;" class=""> Software Engineer |</td><td nowrap="" style="border-top-style: solid; border-top-color: rgb(0, 153, 57); border-top-width: 2px;" class=""> <a href="mailto:tejohnson@google.com" target="_blank" class="">tejohnson@google.com</a> |</td><td nowrap="" style="border-top-style: solid; border-top-color: rgb(238, 178, 17); border-top-width: 2px;" class=""> 408-460-2413</td></tr></tbody></table></span></div></div></blockquote></div><br class=""></div></div></body></html>