[PATCH] D128591: Transforms: Relax restrictions on pow(x, y) expansion

Simon Pilgrim via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Jul 4 06:29:19 PDT 2022


RKSimon added a comment.

In D128591#3625167 <https://reviews.llvm.org/D128591#3625167>, @pawosm01 wrote:

> Hi @RKSimon, thanks for your comments, although I'd like to obtain some of your guidance on what can I do to address them in the context of this commit.
>
>> It seems problematic that LibCallSimplifier::optimizePow also folds pow ->powi yet we also have pow expansion code that is completely separate from powi (where its handled in CGP).
>
> Does it mean that in order to make things less problematic, all applications of createPowWithIntegerExponent() should be moved somewhere else? Or maybe `pow`/`powf`/`powl` expansion code should not occur in optimizePow()? Should the scope of this commit be extended towards such refactor?

I'd expect a powi intrinsic instead of expanding the pow multiplies directly - the sqrt variant should be able to fed into the powi intrinsic as well afaict.

>> We now have TTI:isBeneficialToExpandPowI to decide when to expand powi intrinsics properly instead of hard coded limits like there are here.
>
> Should it happen the same way for `pow`/`powf`/`powl` too?

Yes - create the powi intrinsic and leave it CGP and the backend to decide when to expand it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128591



More information about the llvm-commits mailing list