We had some code for this for 32-bit ARM, but this doesn't really need to be in target-specific code; generalize it.
(I think this started showing up recently because we added an optimization that converts pow to powi.)
Differential D69013
[AArch64][X86] Don't assume __powidf2 is available on Windows. efriedma on Oct 15 2019, 5:35 PM. Authored by
Details We had some code for this for 32-bit ARM, but this doesn't really need to be in target-specific code; generalize it. (I think this started showing up recently because we added an optimization that converts pow to powi.)
Diff Detail
Event TimelineComment Actions I do believe that we need it for all the targets (x86, x86_64, armv7, aarch64).
Comment Actions I tried to get clang to make llvm.powi from C, but it was challenging. Setting -fno-math-errno was what ended up mattering, and even then, I couldn't go from llvm.pow.f64 to powi. Then, I used powi directly from LLVM IR, and I couldn't get it to generate a libcall for x86. It just does repeated multiplication. So, I guess we don't need to do anything for x86?
Comment Actions
Okay.
We generally don't generate the libcall when the power is constant, only when it's a variable. To make clang form powi from pow, I think you need -ffast-math. Try something like the following: double pow(double,double); double f(double x, int y) { return pow(x,y); } Comment Actions I do like @rnk's suggestion for the emission of the error, but Im not really tied to it - if it triggers, the TLI for the target is not setup properly or is missing the symbol, in which case, it needs to be addressed anyways. Beyond that, assuming that @rnk is okay with this, LGTM. Thanks for fixing this.
Comment Actions Updated. I'm a little uncomfortable with the untested codepath, but I guess it isn't any worse than report_fatal_error, which always kills the process. Comment Actions lgtm These days I'm trying to take a hard look at report_fatal_error and ask why it's not either unreachable, assert, or error. |