Fix mistakes that reames' pointed.

Rebase and ping.

Create a new interface SplitBlockAndInsertForLanes, similar as
SplitBlockAndInsertForEachLane but have input argument to control end index.

Use CreateElementCount and fix typos in LangRef.rst.

This update does,

1. Make vp.powi follows llvm.powi to only accept scalar exponent.
2. Add tests for RISC-V.
3. Update test cases.

I think we should follow rule of powi first.

Remove the redudant line.

Use any_<op> to replace base operations and strict operations.

More STRICT_FP_EXTEND_VL after STRICT_FCVT_W_RV64.

Use any_riscv_fpextend_vl to replace riscv_fpextend_vl and riscv_strict_fpextend_vl.

Rebase and ping @aprantl.

LGTM.

Also expanding llvm.powi.

Use distinct debug infromation for different items.

Address sdesmalen comment and refine test cases.

In D143578#4142322, @craig.topper wrote:

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

My plan is use same expanding function but use true mask for its mask and the elementcount for its evl.

In 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?

Update test case.

Address Craig's comment.

Rebase and ping.

In D144075#4128393, @RKSimon wrote:

LGTM - do you have other patches dependent on this already or is it prep for future VP work?

Use vp.icmp instead of icmp.

Cleanup headers.

Address Craig's comment and add missing test case.

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.

LGTM. Thank you.

Use is_same_v and rename getVPForFunctionOpcode to getVPForBaseOpcode.

Rename getFunctionOpcodeForVP to getBaseOpcodeForVP.

Split getNode of VPMatchContext to some with SDNodeFlags and others with SDNodeFlags.

Rebase and fix typos.

Address Craig's comment.

Address Craig's comment.

@simoll There is some difference between my implement and yours:

1. Operand with true mask does not fail in match() of VPMatchContext.
2. Operand with normal opcode does not fail in match() of VPMatchContext if its opcode is same as the input opcode.
3. Make VPMatchContext be only constructed by vp root nodes. It could help for point 2.
4. I removed the member function getFunctionOpCode and isCompatible.

Rebase and fix typos.

Rebase and update test cases.

Address missing comment in last update.

Address Craig's comment.

Fix typos in commit message.