[PATCH] Caller/Calllee unsafe-fp-math attribute fixup prior to inlining.

[Owen Anderson]

On May 5, 2014, at 11:47 AM, Chandler Carruth <chandlerc at google.com> wrote:

> 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.
> 
> 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.

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.

1) Existing functionality is semantically broken.  We will inline numerically-sensitive procedures into fast-math-enabled functions, likely breaking their functionality.

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.

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 *will* dramatically impact performance of fast math use cases if we do this.

We should not be rejecting improvements because of a far-distant, “perfect” vision for which we have no roadmap, and we *definitely* should not be regressing major use cases!

—Owen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140505/7cb7baef/attachment.html>