Tentative changes to address some comments from the reviewers.

I'm not sure on some parts, but I have prepared a major update for this patch that I hope will fix most of @sdesmalen concerns.

In D72799#1822788, @efriedma wrote:

In D72799#1822599, @dancgr wrote:

In D72799#1822588, @efriedma wrote:

Can we also also add mul patterns for targets that have SVE, but not SVE2?

That instruction is restricted to SVE2. Do we have unpredicated vector mul instructions for SVE targets as well?

We can synthesize a predicate using ptrue. We do this in a few places currently; for example, to implement bswap.

In D72799#1822588, @efriedma wrote:

Can we also also add mul patterns for targets that have SVE, but not SVE2?

Fix whitespace errors and add a couple negative tests for invalid input.

In D72654#1818201, @efriedma wrote:

Do we have any negative tests, for immediates that are outside the range of the sve mul immediate instruction?

@efriedma Any other remarks on this patch?

Updated some minor changes.

Update to use default ISD:SMAX variety.

In D71779#1795054, @efriedma wrote:

Wong SMAX; you're referring to VECREDUCE_SMAX, which isn't relevant here. There is no IR intrinsic for ISD::SMAX; it's pattern-matched from select instructions.

As far as I know the ISD::SMAX only takes one input (https://llvm.org/docs/LangRef.html#llvm-experimental-vector-reduce-smax-intrinsic), in this case we need two inputs so we can do the max between the input vector and the immediate value.

For llvm/test/CodeGen/AArch64/sve-gather-scatter-dag-combine.ll it is still not performing the dag combine, however the resulting assembly is different because this matches with the new AArch64dup pattern for logical vector and immediate AND.

Fix issues with sve gather scatter test.

All changes reverted by commit c7abf8841187c6e2c4169c06226429cdd5650e7f.

This https://reviews.llvm.org/rGeb1857ce0da481caf82271e6d0c9fc745dfab26f fixes this error for now.

Remove unused intrinsic.

Moving SUBR from intrinsics to a reverse pattern match with sub IR instruction.

There are no changes needed after https://reviews.llvm.org/rG002adabb3a251a81ef304353eefb1bf96ec388f6.

I will be merging this patch then, and I will submit a short patch for the AArch64dup (SVELogicalImm32 i64:$imm) patterns and the equivalent ones for the add/sub instructions.

Add specific intrinsic for i64.

b29916cec3f45e5fb5efff5104acf142f348c724

Update minor details.

Add extra check to DAGToDAGISel to avoid invalid immediates.

Fix some formatting and apply suggested changes.

• [AArch64][SVE] Update intrinsic to include Immediate option and remove sign handling for i16 immediate for add/sub.

• [AArch64][SVE] Update intrinsic to include Immediate option and remove sign handling for i16 immediate for add/sub.

• [AArch64][SVE] Rename intrinsics to re-use logical SVE intrinsics.
• [AArch64][SVE] Change bic instrincis to comply with other predicated instructions
• [AArch64][SVE] Remove trailing backslash from test

• [AArch64][SVE] Remove trailing backslash from test

• [AArch64][SVE] Change bic instrincis to comply with other predicated instructions

Added final touches.

Done all changes suggested by @sdesmalen. I removed the unnecessary changes to AArch64 patterns, did all of the small details and added nxv2i64 sddv mapping to uaddv.

Added intrinsics re-name before committing as suggested by @sdesmalen.

• [AArch64][SVE] Rename intrinsics to re-use logical SVE intrinsics.

Do any of the reviewers have other suggestions for this patch?

• [Transform][InstCombine] Add new test case for the specified scenario.

I think I have addressed all of the comments from the reviewers on this patch. This way we don't have any new legal type and I embedded the insert_subreg in the helper pattern.

Add context.

Also the change on unrelated patterns it to avoid ambiguities in the FPR8 and FPR16 patterns.

I have added the FPR8 and FPR16 outputs for the SVE Integer reductions.

• [AArch64][SVE] Add FPR8 and FPR16 types for SVE integer reduction.

In D70462#1752506, @lebedev.ri wrote:

-1 to adding more artificial one-use restrictions.
I agree there is a general problem of unability to see if
there exists a particular instruction already.

@sdesmalen, would you have any objections if I implemented it as @efriedma suggested?

Removed unused Intrinsic as requested.