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

[Fraser Cormack via Phabricator via llvm-commits]

frasercrmck added a comment.

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.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143578