[PATCH] D143578: [VP] Add vp.powi and a pass for expanding vp.powi before DAG.

Craig Topper via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Mar 15 15:20:19 PDT 2023


craig.topper added a comment.

In D143578#4197721 <https://reviews.llvm.org/D143578#4197721>, @reames wrote:

> In D143578#4142322 <https://reviews.llvm.org/D143578#4142322>, @craig.topper wrote:
>
>> How would we expand the other math functions? Many of them are large and probably difficult to keep in vector form. We could scalarize them with a loop and use scalar libcalls.
>
> I want to second this point.  I think doing the fancy expansion here is a bad idea at this time.  We can come back to that, but an initial implementation should scalarize via a loop.  The lowering works for all of the lane-wise math routines.  Only once we have correct lowering for the majority of the routines should we bother optimizing any of them.
>
> Even then, I'm not convinced that inlining this loop is profitable over generating a runtime call to a new routine.

I want to mention that powi is weird and does not correspond to a real math routine. It's a fast math optimization for pow with an integer argument. The scalar version of powi is provided in libgcc/compiler-rt while pow itself is in libm. This almost makes it a compiler implementation detail. Should a vector math library provide this function?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D143578/new/

https://reviews.llvm.org/D143578



More information about the llvm-commits mailing list