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
pow
orpowf
in 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
FPowSI
to a call of the inlined implementation always, OR - Convert
FPowSI
withi32
power 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.