For that reason I think the LLVM dialect should probabaly keep it unrestricted.
Okay, thank you for the clarification. Then it sounds like MathToLLVM convertor may only rely on llvm::PowIOp supporting only i32 power operand, unless there is a way to query the target for the supported power operand types during this conversion. I am not aware whether this is possible currently.
Would this then call
poworpowfin libc or would it have a an inline implementation such as the patch you posted?
Representing power operation with integer power operand via libm is possible with extending the power operand bitwidth, e.g. POWER(base, power_i32) can be computed via double-precision libm’s pow((double)base, (double)power_i32). I am not in favor of such a conversion mainly due to performance reasons.
So I see two alternatives to this:
- Convert
FPowSIto a call of the inlined implementation always, OR - Convert
FPowSIwithi32power operand tollvm::PowIOp(which then will be transformed into a call to LLVM’s compiler-rt/libgcc__powi*function), otherwise, convert it into a call of the inlined implementation.
I prefer the second one even though it is kind of a fragmented solution, but I expect better performance from the specialized handling of llvm.powi.* in LLVM backend.