<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: arial,helvetica,sans-serif; font-size: 10pt; color: #000000'><br><hr id="zwchr"><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><b>From: </b>"Mehdi Amini via llvm-dev" <llvm-dev@lists.llvm.org><br><b>To: </b>"Mehdi Amini" <mehdi.amini@apple.com><br><b>Cc: </b>llvm-dev@lists.llvm.org, "cfe-dev" <cfe-dev@lists.llvm.org><br><b>Sent: </b>Thursday, November 17, 2016 11:43:33 AM<br><b>Subject: </b>Re: [llvm-dev] RFC: Consider changing the semantics of 'fast' flag implying all fast-math-flags<br><br>
<br class=""><div><blockquote class=""><div class="">On Nov 17, 2016, at 9:10 AM, Mehdi Amini via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class=""><blockquote class=""><div class=""><br class="Apple-interchange-newline">On Nov 17, 2016, at 9:00 AM, Sanjay Patel <<a href="mailto:spatel@rotateright.com" class="" target="_blank">spatel@rotateright.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">If we take this argument to its end: any one of those relaxed FP settings *guarantees* that we cannot ensure that the result will be the same between two versions of clang. Therefore, we can no-op all of them, and greatly simplify the optimizer.<span class="Apple-converted-space"> </span><br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">I don’t understand the logic here.</div></div></div></blockquote><div><br class=""></div><div id="DWT4130">I understand now, and I think I answered below: yes we “can" no-op all of them, and no we don’t do it because they are valuable, because we find them useful, not because GCC expose them on its command line.</div></div></blockquote>I think this is exactly right. We should support these flags because they're useful to our users (which they are). We should support reasonable subsetting of fast-math because that's useful to our users (which it is to the extent that we currently support and will be more useful once we can separately toggle reassociation, etc.).<br><br> -Hal<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><div><div></div><div><br class=""></div><div>— </div><div>Mehdi</div><div><br class=""></div><br class=""><blockquote class=""><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class=""><div class=""><br class=""></div><br class=""><blockquote class=""><div class=""><div dir="ltr" class="">I know that's not what you're advocating, but the suggestion that we remove 'arcp' is the first step on that path. We can't do that. We must make a good faith effort to support these flags.<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">I disagree, we can do it if don’t see any perceived value.</div><div class="">Saying “gcc has this option” does not mean we have to mimic its behavior if it does not make sense to us.</div><div class=""><br class=""></div><div class="">Note: *I* am not in favor of removing arcp, even though I don’t believe Warren’s use-case is really compelling.</div><div class="">— </div><div class="">Mehdi</div><div class=""><br class=""></div><br class=""><blockquote class=""><div class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Thu, Nov 17, 2016 at 9:31 AM, Mehdi Amini<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:mehdi.amini@apple.com" target="_blank" class="">mehdi.amini@apple.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: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="" style="word-wrap: break-word;"><br class=""><div class=""><div class=""><div class="h5"><blockquote class=""><div class="">On Nov 17, 2016, at 8:30 AM, Mehdi Amini <<a href="mailto:mehdi.amini@apple.com" target="_blank" class="">mehdi.amini@apple.com</a>> wrote:</div><br class="m_-1974130613103970878Apple-interchange-newline"><div class=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;"><blockquote class=""><div class=""><br class="m_-1974130613103970878Apple-interchange-newline">On Nov 17, 2016, at 8:03 AM, Sanjay Patel <<a href="mailto:spatel@rotateright.com" target="_blank" class="">spatel@rotateright.com</a>> wrote:</div><br class="m_-1974130613103970878Apple-interchange-newline"><div class=""><div dir="ltr" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;"><div class=""><div class=""><div class="gmail_extra"><div class="gmail_quote">On Thu, Nov 17, 2016 at 2:31 AM, Nicolai Hähnle via llvm-dev<span class="m_-1974130613103970878Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a>></span><span class="m_-1974130613103970878Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="m_-1974130613103970878gmail-HOEnZb"><div class="m_-1974130613103970878gmail-h5">On 17.11.2016 09:51, Ristow, Warren wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Those are all good points. Your reassociation point in the context of<br class="">inlining is particularly interesting.<br class=""><br class=""><br class=""><br class="">FWIW, we also have a case where a customer wants '-fno-associative-math'<br class="">to suppress reassociation under '-ffastmath'. It would take me a while<br class="">to find the specifics of the issue, but it was (if my memory is right)<br class="">more of a real use-case. (That is to say, the code that was "failing"<br class="">due to reassociation didn't have an obvious fix like the reciprocal<br class="">situation, here, other than to turn off fast-math.) In fact, the<br class="">request to suppress reassociation was the motivation for creating<br class="">PR27372 in the first place (which eventually fed into this thread). I<br class="">have to say that on the reassociation point, my concern is that to<br class="">really suppress that, we will have to suppress so much, that there will<br class="">hardly be any point in using -ffast-math.<br class=""><br class=""><br class=""><br class="">I'd say your comments here are very similar to what Nicolai said in<br class="">another subthread of this discussion:<br class=""><br class=""><br class=""><br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">I'd be really curious to know if there is anybody who really needs arcp<br class=""></blockquote></blockquote><br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">without fp-contract=fast or vice versa, or who needs both of these but<br class=""></blockquote></blockquote><br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">not the X*log2(0.5*Y) transform you mentioned, and so on.[1]<br class=""></blockquote></blockquote><br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">...<br class=""></blockquote></blockquote><br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">[1] One case I _can_ think of (and which may have been a reason for the<br class=""></blockquote></blockquote><br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">proliferation of flags in the first place) is somebody who enables fast<br class=""></blockquote></blockquote><br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">math, but then doesn't want their results to change when they update the<br class=""></blockquote></blockquote><br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">compiler and get a new set of optimizations. But IMO that's a use case<br class=""></blockquote></blockquote><br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">that should be explicitly rejected.<br class=""></blockquote></blockquote><br class=""><br class=""><br class="">I think those are all really good points, and an argument can be made<br class="">that when -ffast-math gives you results you don't want, then you just<br class="">have to turn it off. Essentially, the user can't "have his cake and eat<br class="">it too".<br class=""><br class=""><br class=""><br class="">All that said, I think we (the company I work for, Sony) will have to<br class="">implement support for these switches. It comes down to GCC has these<br class="">switches (e.g., -fno-reciprocal-math and -fno-associative-math), and<br class="">they do suppress the transformations for our customers. They switch to<br class="">Clang/LLVM, they use the same switches, and it doesn't "work". So as a<br class="">practical matter, I think we will support them. Whether the LLVM<br class="">community in general feels that that's required, is another question.<br class="">Until for your recent comments here, and Nicolai's comments above, I<br class="">would have thought the answer was clearly yes. But maybe that's not the<br class="">case.<br class=""><br class=""><br class=""><br class="">In summary, irrespective of any (subjective?) assessment of how<br class="">legitimate a particular use-case is, do we want switches like:<br class=""><br class=""><br class=""><br class=""> <span class="m_-1974130613103970878Apple-converted-space"> </span>-ffast-math -fno-reciprocal-math<br class=""><br class=""> -ffast-math -fno-associative-math<br class=""><br class=""><br class=""><br class="">to work?<br class=""><br class=""><br class=""><br class="">For me, the answer is yes, because I have multiple customers that tell<br class="">me they really want to leave -ffast-math on, but they want to be able to<br class="">disable these sub-categories. I've been approaching this under the<br class="">assumption that the answer is yes for the Clang/LLVM community in general.<br class=""></blockquote><br class=""></div></div>I feel your pain, but I'm not convinced yet that this is really the right approach.<br class=""><br class="">It sounds like the customers (a) want fast-math in general but (b) have some specific parts of the code where it breaks things. What about having them disable fast-math on a more fine-grained scope, e.g. via something like an __attribute__(no_fast_math) function attribute at the C++ source level?<br class=""><br class="">Then the problematic piece of code might be slower (since all of fast-math is disabled), but the rest of the code would likely be faster (since it benefits from all of fast-math instead of just a subset).<br class=""></blockquote><div class=""><br class="">This is suggesting source code changes to customers that are switching compilers, but (as Warren hinted at) one of the stated goals of clang is GCC compatibility:<br class=""><a href="http://clang.llvm.org/" target="_blank" class="">http://clang.llvm.org/</a><br class=""></div></div></div></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">We don’t aim at being bug-to-bug compatible though.</div><div class="">I believe we are compatible in terms of command line invocation, even if some gcc flags are no-op in clang.</div><div class=""><br class=""></div><br class=""><blockquote class=""><div class=""><div dir="ltr" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;"><div class=""><div class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">If that's still true, it means (barring anything that we explicitly document and choose not to support), we should support GCC's FP options:<br class=""><a href="https://gcc.gnu.org/onlinedocs/gcc-6.2.0/gcc/Optimize-Options.html#Optimize-Options" target="_blank" class="">https://gcc.gnu.org/onlinedocs/gcc-6.2.0/gcc/Optimize-Options.html#Optimize-Options</a><br class=""><br class="">-ffp-contract=style<br class="">-ffast-math<br class="">-fno-math-errno<br class="">-funsafe-math-optimizations<br class="">-fassociative-math<br class="">-freciprocal-math<br class="">-ffinite-math-only<br class="">-fno-signed-zeros<br class="">-fno-trapping-math<br class="">-frounding-math<br class="">-fsignaling-nans<br class="">-fsingle-precision-constant</div><div class=""><br class="">etc, and the relevant negations of these options. We can't predict how customers will choose to chain these together, so I think the LLVM optimizer and backend designs should accommodate all possibilities derived from those clang flags. This includes (because I've seen this requested) using relaxed FP modes and simultaneously enabling some subset of FP exceptions. (I know it sounds crazy... :) )</div></div></div></div></div></div></div></blockquote></div><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;"><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">I am not convinced, because when disabling IEEE compliance we can’t even ensure that the result will be the same between two versions of clang (indeed it won’t in many/most real-world cases), the claim that we are “GCC compatible” has not much value here: the code can still break when built with clang and not when built with GCC, even when disabling fast-math.</div></div></blockquote><div class=""><br class=""></div></div></div><div class="">The last part should read “even when disabling reciprocal”</div><div class=""><br class=""></div><div class="">— </div><div class="">Mehdi</div><div class=""><br class=""></div><br class=""><blockquote class=""><div class=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;"><br class=""></div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;"><br class=""></div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">— </div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">Mehdi</div></div></blockquote></div><br class=""></div></blockquote></div><br class=""></div></div></blockquote></div><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;"><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; float: none; display: inline ! important;" class="">_______________________________________________</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; float: none; display: inline ! important;" class="">LLVM Developers mailing list</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class=""><a href="mailto:llvm-dev@lists.llvm.org" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class="" target="_blank">llvm-dev@lists.llvm.org</a><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class=""><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class="" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a></div></blockquote></div><br class=""><br>_______________________________________________<br>LLVM Developers mailing list<br>llvm-dev@lists.llvm.org<br>http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<br></blockquote><br><br><br>-- <br><div><span name="x"></span>Hal Finkel<br>Lead, Compiler Technology and Programming Languages<br>Leadership Computing Facility<br>Argonne National Laboratory<span name="x"></span><br></div></div></body></html>