[llvm-dev] [PATCH] D14707: add fast-math-flags to 'call' instructions (PR21290)

Sanjay Patel via llvm-dev llvm-dev at lists.llvm.org
Thu Jan 7 10:52:41 PST 2016


On Wed, Jan 6, 2016 at 5:02 PM, Mehdi AMINI <mehdi.amini at apple.com> wrote:

> joker.eph added a subscriber: joker.eph.
> joker.eph added a comment.
>
> I wonder about the design of this, especially since Chris (and Chandler)
> rejected it in the past:
> http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20121217/159446.html
> ?
>
>
> Repository:
>   rL LLVM
>
> http://reviews.llvm.org/D14707
>
>
Thanks, Mehdi. I wasn't aware of that discussion; cc'ing those folks and
llvm-dev.

The earlier proposal distinguished between intrinsics and regular calls,
while this does not. This adds FMF to all calls that are FPMathOperators
(return FP or FP vector). I don't know if that makes it more or less
objectionable than the previous proposal.

Note the earlier suggestions/comments in the Phab review:
We could slide FMF into call instruction attributes, but I thought that was
worse given that FMF continues to evolve ( http://reviews.llvm.org/D14067 ).

There are a handful of places in LibCallSimplifier where we can use FMF on
calls today (and I already changed a few of those in recent commits). That
number will grow over time as we add more optimizations. In theory, we
could also use FMF on calls for DAG optimizations if we extend that too.

The main motivation for putting FMF on a call rather than relying on a
function-level attribute is the LTO case. There are also (insane?)
customers that want to specify relaxed/strict math at whatever granularity
we will allow via pragma in C source code. I think these are the same
motivations that drove FMF for IR FP math instructions in the first place.
This patch get us closer to the goal of mixed fast/strict math in LLVM. If
there's a better way to implement this, I'll try to help make it happen.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160107/c3395007/attachment.html>


More information about the llvm-dev mailing list