[PATCH] D80744: DAGCombiner optimization for pow(x, 0.75) even in case massv function is asked

[Qing Shan Zhang via Phabricator via llvm-commits]

steven.zhang added a comment.

In D80744#2066590 <https://reviews.llvm.org/D80744#2066590>, @masoud.ataei wrote:

> In D80744#2062144 <https://reviews.llvm.org/D80744#2062144>, @steven.zhang wrote:
>
> > What we are doing is as follows:
> >  llvm.pow(IR) --> FPOW(ISD) --> __powf4_P8/9(ISD/IR)
> >
> > It makes more sense to do it in the IR pass from what I see. And then, you can query the TargetLibraryInfoImpl::isFunctionVectorizable(name) instead of the option. Maybe, we can do it in ppc pass: PPCLowerMASSVEntries which did something like:
> >
> >   __sind2_massv --> __sind2_P9 for a Power9 subtarget.
> >
> >
> > Does it make sense ?
>
>
> I agree in general it makes more sense to do this kind of conversions in an IR pass like PPCLowerMASSVEntries. This is what we are currently doing in LLVM but there is a problem here. If we change the llvm intrinsic to libcall earlier than a later optimization (like in DAGCombiner) the later optimization won't be triggered. In the case that I am proposing the change, if we have pow(x,0.75) in the code, the PPCLowerMASSVEntries pass will currently change it to __powf4_P* libcall then later in the DAGCombiner we will not get the optimization `pow(x,0.75) --> sqrt(x)*sqrt(sqrt(x))`. So that's a problem, because sqrt(x)*sqrt(sqrt(x)) is faster.
>
> What I am proposing is to move the conversion for powf4 to late in the compiler pipeline. With this change we will we will get above optimization when exponent is 0.75 and MASSV calls otherwise.


If we expect the llvm.pow(x, 0.75) to be lowered as two sqrt and for others, they are libcall, can we just don't transform it as libcall for 0.75 in PPCLowerMASSVEntries? And it will be lowered as two sqrts in DAGCombine.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80744