[PATCH] Caller/Calllee unsafe-fp-math attribute fixup prior to inlining.
chandlerc at google.com
Mon May 5 12:39:35 PDT 2014
On Mon, May 5, 2014 at 12:14 PM, Owen Anderson <resistor at mac.com> wrote:
> 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.
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.
> 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.
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.
> 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!
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.
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.
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-commits