<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On May 5, 2014, at 11:47 AM, Chandler Carruth <<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">I'm really questioning whether this is worth it at all. These all feel like terrible hacks around a design that just isn't going to work. If we're going to do this at all, I think we should first invest the time to make the unsafe-fp-math attributes first-class attributes. But we don't think that such attributes are the right design, so I don't know why we're investing so much effort into LLVM to hack at them and shove things that are the *wrong design* together to kinda sorta work. Instead, I think we should actually auto-upgrade away these attributes so that they are never seen in the IR at all. The replacement can be per-instruction flags. If we miss some optimizations as a consequence, I'm OK with that until support arrives. If there is some reason why we *must* persist the wrong design, I think we need to spend the time to really flesh out support for these attributes as function attributes. Give them enums, write helper functions, get reasonable intersection semantics, etc.</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">Increasingly, I think we should simply refuse to inline function A into function B if A and B have different string attribute sets because we don't know anything about the semantics there.</div></blockquote></div><br><div>I vehemently disagree with this conclusion. I agree that, in principle, we should find a better global solution to the modeling of fast-math flags (mostly likely by propagating the fine-grained flags through SDISel), but what you’re proposing is not an acceptable solution.</div><div><br></div><div>1) Existing functionality is semantically broken. We will inline numerically-sensitive procedures into fast-math-enabled functions, likely breaking their functionality.</div><div><br></div><div>2) Refusing to inline mismatched attributes without any attempt to reconcile them will fundamentally break always_inline in ways that regress from earlier releases. This will be at the expense of our users.</div><div><br></div><div>3) Killing off the global attributes before we’ve threaded this through SDISel would be an unacceptable performance regression. A lot of fast math functionality occurs in the backends, and we<i> </i>*will* dramatically impact performance of fast math use cases if we do this.</div><div><br></div><div>We should not be rejecting improvements because of a far-distant, “perfect” vision for which we have no roadmap, and we<i> </i>*definitely* should not be regressing major use cases!</div><div><br></div><div>—Owen</div><div><br></div></body></html>