LGTM

LGTM, modulo future changes.

LGTM, modulo future changes

LGTM

LGTM with minor nits

LGTM

• Tighten up checks on bitcast in store case to ensure we have the correct types.
• Remove redundant uzp1 operand check.
• Bail upon encountering non-integer types.

• Remove redundant check against all predicate pattern

• Rename InVT to VT for clarity.
• Check for zero return from getNumElementsFromSVEPredPattern.
• Bail out if passthru is not zero or undef.
• Force passthru to be zero so as to not introduce extra undef bits.

• Ensure we don't try and combine a UUNPKHI.
• Remove incorrect IsExapanding argument to getMaskedLoad.
• Explicitly check for and create new PTRUE for mask.
• Properly check that the PTRUE we are creating can be represented at the current VL.
• Remove extract_subvector ptrue combine as it is no longer needed.

• Add support for i1 vecreduce_and -> vecreduce_umin.

• Further improve clarity on usable types in LangRef

• Clarify LangRef slightly to make it clearer that fixed types can be used
• Rebase on top of recent test changes

In D119661#3477766, @fhahn wrote:

In D119661#3459006, @bsmith wrote:

Is there any update on this change? It provides some nice improvements to various workloads we have been looking at and would be good to get in.

I'm planning to pick this up again fairly soon. There's some other work ongoing to break things up a bit and model codegen for entry & exit values explicitly. I think it would be good to make the transitions for first-order recurrence first and then update the patch.

• Rework to use PatFrags instead of adding extra patterns
• Add tests for intrinsic cases

LGTM

• Add info to release notes

Hopefully soon the vector.insert/extract intrinsics will be moving out of the experimental namespace (https://reviews.llvm.org/D127976). Just a heads up, depending on which patch lands first.

This has turned out to be far more complex to do safely than originally thought, given I don't as of yet have a compelling example where this provides a significant benefit I will abandon this for now.

In D126190#3531596, @xbolva00 wrote:

Is this “safe” even with fast math for all predicates?

• Rebase.
• Move fast math flag requirements from fcmp to sqrt.
• Don't require 'fast' flag on sqrt, only 'nnan && (reassoc || afn)'

• Be stricter around fast math flags and require 'fast' not just 'nnan'.
• Propagate fast math flags through combine.

LGTM

Ah, a quick check suggests your patch also works for our case. I'll abandon this in favour of that one. Thanks!

It should be noted that I'm not 100% certain this patch is sound so would very much like some guidance here, I'm looking to address the discussion from here as we have hit this case: https://reviews.llvm.org/D105942#inline-1007492. It's not clear to me whether more needs to be done to cope with the fact that we are dealing with a poison value here.

• Use m_NonNegative instead of manually checking for splats and their values

• Fix typos in comments, SQSHL -> SRSHL.
• Rearrange tests to have positive cases first.

In D125233#3503702, @david-arm wrote:

Hi @bsmith, this looks like a sensible optimisation! I suppose we can also do something similar when the input is an and too? i.e.

%mask = tail call <vscale x 8 x i16> @llvm.aarch64.sve.dup.x.nxv8i16(i16 0x7FFF)
%and = tail call <vscale x 8 x i16> @llvm.aarch64.sve.and.nxv8i16(<vscale x 8 x i1> %pg, <vscale x 8 x i16> %a, <vscale x 8 x i16> %mask)
%splat = tail call <vscale x 8 x i16> @llvm.aarch64.sve.dup.x.nxv8i16(i16 2)
%shr = tail call <vscale x 8 x i16> @llvm.aarch64.sve.srshl.nxv8i16(<vscale x 8 x i1> %pg, <vscale x 8 x i16> %and, <vscale x 8 x i16> %splat)

• Rework patch to use same mechanism as stack realignment, rather than using base pointer.

• Only restore from base pointer when SVE CSRs are present

• Add testcase protecting original issue
• Add explict false return for invalid frame index

• Update test to use update_llc_test_checks.py script

In D124457#3476866, @bsmith wrote:

In D124457#3474976, @efriedma wrote:

Is FrameIndex 0 actually reliably located in a position that doesn't have an offset? That seems unlikely to me, especially if variable-size allocation becomes involved.

Hm, you might be right. It seems a shame to regress cases where the index would be zero, but I'm not sure there is way to tell at this point if the offset will resolve to zero?

Alternatively, we could fix the code that decides whether we need an emergency spill slot. But I guess there's not really much point to attempting to fold the frame indexes in the first place.

I considered that, the issue though is finding the correct condition to do this in without being far too conservative, I think you'd have to do it by traversing the function finding all SVE load/stores and checking what they access, which doesn't seem very nice for an issue we are creating for ourselves.

In D124457#3474976, @efriedma wrote:

Is FrameIndex 0 actually reliably located in a position that doesn't have an offset? That seems unlikely to me, especially if variable-size allocation becomes involved.

Is there any update on this change? It provides some nice improvements to various workloads we have been looking at and would be good to get in.

LGTM!

This all looks reasonable to me, but I'll let @peterwaller-arm have the final say.

LGTM!

• Tighten check around type sizes

• Tighten type size check
• Move test to already existing file
• Add rudimentary check lines to test

LGTM with minor nits.