In D144951#4157914, @nikic wrote:

I doubt that this was an intended feature -- just a side effect of how the intrinsic type constraints work. They always assume vectors are allowed for llvm_anyint_ty.

Just a glancing review but, to me, "expand pseudos" has a more immediate connotation of the many pseudo expansion passes (e.g., RISCVExpandPseudoInsts) than "expanding the set of pseudos" as you seem to intend it.

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

Maybe I missed the rationale, but why not use the ExpandVectorPredicationPass for this?

Superseded by D139873 amongst others

Bit late to the party, but thanks for doing this

LGTM other than test header comment that needs changed.

LGTM other than nits

Thanks for kicking this off. Unfortunately I don't have the time right now to give an in-depth review.

LGTM (with nit) - I couldn't find or think of any problems arising from this.

LGTM

LGTM too, with some minor suggestions

LGTM

In D137516#3911245, @arsenm wrote:

I think this is fine, but think the name needs to be bikeshedded. "Target" and "Support" are already overloaded enough as it is. Is there anything else that would really ever go into this library?

LGTM

LGTM other than a nit, but I concur that a comment in AutoUpgrade would be nice.

I agree with @reames, though I do think the patch description could use a rewrite.

Seems like a reasonable approach to me. I feel it's too difficult for targets to account for the alignment of non-default stack IDs themselves. And that's without your suspicions that scalable vectors may not even be knowingly excluded at the present time.

LGTM

Does anything in the callee expect/rely on the alignment? I'm wondering if it's possible that a caller with one subtarget uses a lower alignment than its callee with another subtarget, causing issues.

LGTM too - makes sense.

LGTM

add missing case, update examples sections

rebase

LGTM

LGTM

LGTM

In D134785#3820372, @eopXD wrote:

This patch is for llvm.roundeven, llvm.vp.roundeven was covered in D134759.

Fixed-vector tests should be in fixed-vectors-round-vp.ll

In D132978#3817541, @Petar.Avramovic wrote:

Other type of regression is when i32 (marked as signed argument) has to be zero-extended to i64 (and with mask), before it used to be a copy. Considering langref changes it is probably more correct to mark index arguments as zeroext (index will be copied again no code size regression). But this should be checked with people who know more about specific targets.

Fixed vector tests?

In D134586#3818275, @craig.topper wrote:

In D134586#3817430, @frasercrmck wrote:

Forgive me if I've missed something but you're adding support for widening and splitting in the legalizer without adding tests for that behaviour.

There's a <vscale x 7 x double> <vscale x 16 x double>, <15 x double> and <32 x double> test. Does that cover it?

Forgive me if I've missed something but you're adding support for widening and splitting in the legalizer without adding tests for that behaviour.

In D134474#3817397, @frasercrmck wrote:

LGTM but I have seen that we have some %t and %also.r mismatches throughout the LangRef that were introduced with the more recent VP intrinsics that have probably since been copy/pasted.

LGTM but I have seen that we have some %t and %also.r mismatches throughout the LangRef that were introduced with the more recent VP intrinsics that have probably since been copy/pasted.

LGTM. Thanks, this has been on my list for a long while but I've not had the bandwidth to do much upstreaming recently.

I think some level of verification makes sense. I half worry that some instructions may not behave so nicely and we'll have to add exceptions to our rules, but none come to mind right now.

LGTM

LGTM too

Looks good to me.

Thanks for doing this!

Do we need a new test in expand-vp.ll? It seems that test has been forgotten about somewhat. There's no fneg in there. Maybe the expansion for that hasn't been implemented? Hard to keep track.

LGTM

LGTM

The change LGTM but I'd like to know why only VP INT_TO_FP nodes are handled in this code.

LGTM

LGTM, thanks for the well-written description.

LGTM

In D129735#3652303, @kito-cheng wrote:

Sorry, I've not had time to think about this today. Just wanted to check: does this pass actually fix the test I added in D129639? Because that isn't (obviously) using undef input values, at least in the IR.

Short answer is yes, but come with few more vmv.v.i instruction for prevent allocated same reg, poison and undef all turn into IMPLICIT_DEF in back-end.