Expand the number of cases when pow(x, 0.5) is simplified into sqrt(x) by considering the math semantics with more granularity.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
llvm/test/Transforms/InstCombine/pow-sqrt.ll | ||
---|---|---|
8–10 | Why change the data types? | |
20 | The minimal test for this case requires no FMF? | |
30–31 | Why change the data types? Same question for the later tests - the types should be irrelevant to the change in functionality, right? Please make any IR changes to the tests that are necessary to show off the improved/fixed functionality as a preliminary step to this review. |
I'll commit the data type changes increasing type diversity on the side.
llvm/test/Transforms/InstCombine/pow-sqrt.ll | ||
---|---|---|
8–10 | In order to increase test coverage. Otherwise, it virtually tested for double only. | |
20 | IIUC, not all of them, just AFN. | |
30–31 | Replacing AFN for NINF shows the improved functionality. |
llvm/test/Transforms/InstCombine/pow-sqrt.ll | ||
---|---|---|
8–10 | Tests are cheap. Couldn't you just *add* the additional test coverage with floats? |
llvm/test/Transforms/InstCombine/pow-sqrt.ll | ||
---|---|---|
8–10 | Yes, you're right. |
llvm/test/Transforms/InstCombine/pow-sqrt.ll | ||
---|---|---|
20 | 'afn' means this transform can diverge from the original code in some way, but I don't think that's true here. Ie, sqrt(x) should be the same as pow(x, 0.5) for all values other than -0.0 and -INFINITY. |
llvm/test/Transforms/InstCombine/pow-sqrt.ll | ||
---|---|---|
20 | The test originally had AFN, so I aimed at preserving it. |
llvm/test/Transforms/InstCombine/pow-sqrt.ll | ||
---|---|---|
20 | It's not obvious where the holes are in the existing code, so I added tests at: If you want to vary the data types more in those tests, feel free. But I think that should provide coverage for everything that is changing in this patch based on FMF + libcall vs. intrinsic. Please rebase this patch with those tests. |
Why change the data types?