[VP] Mark llvm.experimental.vp.splice as having no functional equivalent

[lukel97]

llvm.experimental.vp.splice has different semantics from
llvm.experimental.splice (since it takes uses the EVL arguments in a way other
than just masking the tail elements), so it shouldn't be expanded to the
unpredicated version.

Coincidentally there's no support for llvm.experimental.vp.splice in
ExpandVectorPredication, so it wasn't getting expanded, but we shouldn't mark
it as functionally equivalent anyway since there's other users of the property
now e.g. in VectorCombine.

[llvmbot]

@llvm/pr-subscribers-llvm-ir

Author: Luke Lau (lukel97)

Changes

llvm.experimental.vp.splice has different semantics from
llvm.experimental.splice (since it takes uses the EVL arguments in a way other
than just masking the tail elements), so it shouldn't be expanded to the
unpredicated version.

Coincidentally there's no support for llvm.experimental.vp.splice in
ExpandVectorPredication, so it wasn't getting expanded, but we shouldn't mark
it as functionally equivalent anyway since there's other users of the property
now e.g. in VectorCombine.

---

Full diff: https://github.com/llvm/llvm-project/pull/70647.diff

1 Files Affected:

• (modified) llvm/include/llvm/IR/VPIntrinsics.def (+1-1)

diff --git a/llvm/include/llvm/IR/VPIntrinsics.def b/llvm/include/llvm/IR/VPIntrinsics.def
index 55a68ff5768ddb0..0ca60bcfbb3d03f 100644
--- a/llvm/include/llvm/IR/VPIntrinsics.def
+++ b/llvm/include/llvm/IR/VPIntrinsics.def
@@ -699,7 +699,7 @@ VP_PROPERTY_NO_FUNCTIONAL
 END_REGISTER_VP(vp_merge, VP_MERGE)
 
 BEGIN_REGISTER_VP(experimental_vp_splice, 3, 5, EXPERIMENTAL_VP_SPLICE, -1)
-VP_PROPERTY_FUNCTIONAL_INTRINSIC(experimental_vector_splice)
+VP_PROPERTY_NO_FUNCTIONAL
 END_REGISTER_VP(experimental_vp_splice, EXPERIMENTAL_VP_SPLICE)
 
 ///// } Shuffles

[RKSimon]

Should we just drop handling for it for now or is it possible to create a test case?

[lukel97]

Should we just drop handling for it for now or is it possible to create a test case?

We don't currently handle it in ExpandVectorPredication.cpp to begin with, but I guess we might in future?
I ran through all the users of VPIntrinsic::getFunctionalOpcode()/VPIntrinsic::getFunctionalIntrinsicID()/VPIntrinsic::getConstrainedIntrinsicID() anyway. Looks like the only users are ExpandVectorPredication.cpp and the scalarizeVPIntrinsic combine in VectorCombine.cpp, but the latter only operates on binary ops so it would never have triggered to begin with. So I don't think it's possible to write a failing test case currently.

[RKSimon]

So would we be better off removing it until we have an actual use case?

[lukel97]

So would we be better off removing it until we have an actual use case?

By "it" do you mean removing the VP_PROPERTY_FUNCTIONAL_INTRINSIC property? Or the actual experimental.vp.splice intrinsic?
We can't remove the former without replacing it with VP_PROPERTY_NO_FUNCTIONAL as of #66199, because now we statically assert that every intrinsic has their functional equivalent marked, if that's what you mean

[RKSimon]

Thanks for the explanation! LGTM