This patch enables folding following expressions under -ffast-math flag: exp(X) * exp(Y) -> exp(X + Y), exp2(X) * exp2(Y) -> exp2(X + Y). Motivation: https://bugs.llvm.org/show_bug.cgi?id=35594
Details
Diff Detail
Event Timeline
lib/Transforms/InstCombine/InstCombineMulDivRem.cpp | ||
---|---|---|
736 | Also, ->hasOneUse() checks here. |
Since I'm new to llvm, I looked though other test files, and noticed that it isn't necessary to write full test-check, instead people write just one instruction to make sure test is ok, while consequent instructions doesn't matter. I wonder what style is preferred?
Checks used to be mostly written by hand (and had a lot of shortcomings and bugs because of that). Now that we have scripts to auto-generate checks, I prefer that you use those scripts when possible. It should make subsequent changes or additions to the test file easier for other contributors.
test/Transforms/InstCombine/fmul-exp.ll | ||
---|---|---|
16 | Please cleanup testcases, name all the variables (-instnamer will help) | |
31–32 | I think this can still be transformed, as long as at least one of them has only one use. %2 = call fast double @llvm.exp.f64(double %b) call void @use(double %2) %t1 = add fast double %a, %b %t2 = call fast double @llvm.exp.f64(double %t2) ret double %t2 which has the same number of instruction, | |
test/Transforms/InstCombine/fmul-exp2.ll | ||
68 | Please add newlines |
test/Transforms/InstCombine/fmul-exp.ll | ||
---|---|---|
63 | We don't need the full "fast" to enable these transforms. Can you adjust the tests to show the minimal amount of FMF necessary to allow the optimizations? We need "reassoc" + anything else? Do you have commit access? If so, please commit these files to trunk with the current (without this code patch) output. |
test/Transforms/InstCombine/fmul-exp.ll | ||
---|---|---|
63 | I have commit access, but I don't want to commit without patch approval. Revision is fixed according to your comments. |
test/Transforms/InstCombine/fmul-exp.ll | ||
---|---|---|
31–32 | This comment has not been addressed. I agree with Roman - if there's only 1 extra use, it makes sense to reduce the dependency chain and reduce fmul to fadd. | |
63 | Thanks. I think the patch is close to approval, so you should commit the tests now. There are 2 benefits to committing the tests first:
|
test/Transforms/InstCombine/fmul-exp2.ll | ||
---|---|---|
74 | Hm that is interesting, somehow i have never seen that before. |
LGTM
test/Transforms/InstCombine/fmul-exp2.ll | ||
---|---|---|
74 | 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: |
Also, ->hasOneUse() checks here.