What test suite did you use to demonstrate performance?

In D159494#4642795, @RKSimon wrote:

Please can you add the i686 test coverage seperately as a pre-commit?

done

address the comment

In D159491#4642796, @RKSimon wrote:

(style) Remove the braces around each case statment - we should only need those if we have a local variable

Adrress the comment

In D159495#4642794, @RKSimon wrote:

Please make sure you generate your diffs with context git diff -U9999 HEAD etc.

Add 686 test

In D129173#4259845, @benshi001 wrote:

My suggestion,

1. improve your commit info, something like

Spill/reload instructions are artificially generated by the compiler and
have no relation to the original source code. So the best thing to do is
not attach any debug location to them (instead of just taking the next
debug location we find on following instructions).

Refered to https://reviews.llvm.org/rG3e081703c349dd00b8ef6991c2d15964915dd8f4

2. add some tests as you did in your another review request.

In D140604#4039078, @ftynse wrote:

The actual comment was not addressed:

The commit description still doesn't describe the details of what it is doing and why, only confuses the reader. The code before this commit *was folding trunc(ext)"! This commit does *not* add that. It does, however, *fix* a case that was mishandled. Please find the appropriate way to express that.

address the comments

ping

ping

address the comment

address the comment

ping

ping

ping

LGTM

adress the comment

In D139770#3986487, @jpienaar wrote:

This moves the builder's C++ code from C++ to tablegen we normally try to keep C++ code in ODS files for minimum. If you want this generated you could implement the infer result type interface on this op and then you'd not need to define any custom builder AFAICS.

ping

ping

I am so sorry! Now I have fixed the failed test case, pls review it! https://reviews.llvm.org/D134413

Fixed failed test cases

thanks for helping me revert it！But I'm a little curious, why the submitted patch doesn't trigger the wrong case？？

ping

In D134413#3808618, @david-arm wrote:

I think the change seems sensible because the cost of a NEON load is probably similar to the cost of a SVE masked load on CPUs with SVE. However, I am curious to learn about the problem you're hitting. Are you looking at a specific benchmark or loop where the cost is too high to vectorise with SVE? Or is the cost preventing additional interleaving in the vectoriser?

ping

ping