[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