[all-commits] [llvm/llvm-project] 19f9f3: [SimplifyLibCalls] require fast-math-flags for pow...

[RotateRight via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 19f9f374d9afe3efd33dc1943d3d7fd2c54fba76
      https://github.com/llvm/llvm-project/commit/19f9f374d9afe3efd33dc1943d3d7fd2c54fba76
  Author: Sanjay Patel <spatel at rotateright.com>
  Date:   2019-12-21 (Sat, 21 Dec 2019)

  Changed paths:
    M llvm/lib/Transforms/Utils/SimplifyLibCalls.cpp
    M llvm/test/Transforms/InstCombine/pow-sqrt.ll

  Log Message:
  -----------
  [SimplifyLibCalls] require fast-math-flags for pow(X, -0.5) transforms

As discussed in PR44330:
https://bugs.llvm.org/show_bug.cgi?id=44330
...the transform from pow(X, -0.5) libcall/intrinsic to
reciprocal square root can result in small deviations from
the expected result due to differences in the pow()
implementation and/or the extra rounding step from the division.

This patch proposes to allow that difference with either the
'approximate functions' or 'reassociate' FMF:
http://llvm.org/docs/LangRef.html#fast-math-flags

In practice, this likely means that the code is compiled with
all of 'fast' (-ffast-math), but I have preserved the existing
specializations for -0.0/-INF that enable generating safe code
if those special values are allowed simultaneously with
allowing approximation/reassociation.

The question about whether a similar restriction is needed for
the non-reciprocal case -- pow(X, 0.5) -- is deferred. That
transform is allowed without FMF currently, and this patch does
not change that behavior.

Differential Revision: https://reviews.llvm.org/D71706