[PATCH] D41342: [InstCombine] Missed optimization in math expression: simplify calls exp functions

Sanjay Patel via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Jan 30 08:03:14 PST 2019


spatel accepted this revision.
spatel added a comment.

LGTM



================
Comment at: test/Transforms/InstCombine/fmul-exp2.ll:74
+; CHECK-NEXT:    [[TMP2:%.*]] = fadd reassoc double [[TMP1]], [[D:%.*]]
+; CHECK-NEXT:    [[TMP3:%.*]] = call reassoc double @llvm.exp2.f64(double [[TMP2]])
+; CHECK-NEXT:    ret double [[TMP3]]
----------------
Quolyk wrote:
> lebedev.ri wrote:
> > Hm that is interesting, somehow i have never seen that before.
> > So the FMF can be set on such intrinsic calls too.
> > Here, we only need `reassoc` on the original `fmul`, not the `exp`?
> I've been experimenting with this. As @spatel mentioned we need minimum `reassoc` calls here. So as it appears we need all `fmul reassoc`, however `call double` doesn't need `reassoc`.
Yes, FMF can be set for any call. IIRC, we first needed this for llvm.sqrt, but it can be used with any FP call.

And yes, FMF is only required on the fmul here because that value has loosened strictness, so we assume that intermediate values leading up to it may also use that loosened strictness to compute the final result. We should probably make that clearer in the LangRef.

The flag requirement that trips me up most often on these is 'nsz', but I think we're safe here:
exp2(+/-0.0) * exp2(+/-0.0) --> 1 * 1 --> 1
exp2((+-0.0) + (+/-0.0)) --> exp2(+/- 0.0) --> 1


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D41342/new/

https://reviews.llvm.org/D41342





More information about the llvm-commits mailing list