[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
Tue Feb 21 10:55:49 PST 2023


craig.topper added a comment.

In D143578#4140944 <https://reviews.llvm.org/D143578#4140944>, @frasercrmck wrote:

> In D143578#4113149 <https://reviews.llvm.org/D143578#4113149>, @fakepaper56 wrote:
>
>>> Maybe I missed the rationale, but why not use the ExpandVectorPredicationPass for this?
>>
>> LLVM could not expanding scalable vector type `powi` now. So this pass is not only for `vp.powi`, but also expanding scalable vector type `powi` in the future.
>
> Apologies, I was away on holiday.
>
> Thanks - I missed that the plan was also to support `llvm.powi`. I guess I just find `ExpandPowi` and `ExpandVectorPredicationPass` to be doing two very similar things (in this patch) with regards to `vp.powi`: expanding it into an equivalent set of operations; that seems unfortunate.
>
> I get that scalable-vector `llvm.powi` is different, but so would many other scalable-vector intrinsics if the target doesn't support that operation: `llvm.sin`, `llvm.cos`, etc. So would we have passes for each intrinsic? If not, `ExpandPowi` seems too restrictive in its scope.
>
> If we're supporting intrinsics, what about plain scalable-vector `add` on a target without scalable vectors, like x86?
>
> I'd basically like to know how this fits in with some longer-term strategy about what we want to support for illegal scalable-vector operations, rather than this specific `powi` use-case. If we start to open the door to specific intrinsics, I think it'd help to have a well-defined rationale and plan in mind.

Note that this pass doesn't scalarize

In D143578#4141678 <https://reviews.llvm.org/D143578#4141678>, @fakepaper56 wrote:

> In D143578#4140944 <https://reviews.llvm.org/D143578#4140944>, @frasercrmck wrote:
>
>> I get that scalable-vector `llvm.powi` is different, but so would many other scalable-vector intrinsics if the target doesn't support that operation: `llvm.sin`, `llvm.cos`, etc. So would we have passes for each intrinsic? If not, `ExpandPowi` seems too restrictive in its scope.
>>
>> If we're supporting intrinsics, what about plain scalable-vector `add` on a target without scalable vectors, like x86?
>
> I agree with you that only expanding powi is too restrictive. I think at least we should expand all the math function in a pass. But I don't have no idea that whether we should expand scalable operations for target without scalable vectors?

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. But that makes it very different than what we're doing for powi here.

How do envision sharing this code for llvm.powi. A lot of this code creates VP intrinsics. Do you have an abstraction plan?


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