<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 5, 2014 at 12:14 PM, Owen Anderson <span dir="ltr"><<a href="mailto:resistor@mac.com" target="_blank">resistor@mac.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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></blockquote><div><br></div>
<div>No argument from me here. That said, we need to figure out *some* path forward. I would be happy with a lot more in the way of an incremental step if there were some follow-up step coming, but so far I don't see any.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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>
</blockquote><div><br></div><div>Is this true for any textual attributes other than fast-math ones? I can't think of any, and I'm not suggesting this for fast-math flags. I understand the problem there.</div><div>
 </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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></blockquote></div>
</div><div class="gmail_extra"><br></div><div class="gmail_extra">If there is no roadmap and essentially no one working on actually modeling the instruct flags fully, then fine. We should promote all of the unsafe fp math flags to be formal attributes rather than string attributes, and then model their semantics. They'll be around forever if no one works on it, so we'll have to live without a better solution. By making them full blown attributes we can more reasonably teach the entire optimizer how to interact correctly with them.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">What I don't want to get the inliner (or any other part of the IR-optimizer) into the business of reasoning in a precise (and thus easily broken) way about the semantics of arbitrary textual attributes. Textual attributes make much more sense when the IR transforms don't need to reason about them in any amount of detail. And I don't want to add "just one" such case for the unsafe fp math flags because it will both invite more (no matter what we say) and be a long term maintenance headache. The textual attributes are intentionally opaque to the IR, so it gets *really* ugly to try and map some semantic onto them.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Naturally, I don't want to regress users. =/ I'm just trying to not create still more problems down the road. I don't see any way to do that with textual attributes.</div>
</div>