The code generated for inserting the scalar result of a 'uaddlv' intrinsic function to a vector exhibits a redundant move to the integer register first, & then moves it back to the destination vector Neon register. This can be done directly. In my understanding, this issue occurs because the selected instruction for vector insertion expects an i32/i64 integer register to hold the value and the selected instruction for the 'uaddlv' function is giving an output of i32/i64 at the instruction selection time, whereas in practice the result of 'uaddlv' goes to a Neon register. Therefore I added patterns to match the combined use of these two instructions (uaddlv & vector_insert), to generate the direct move from the source to destination Neon register.

Addressed the final comments in a separate commit.

Added an assert for an extra check

Trying to fix patching error

Re-based on newly added tests

Added an extra unit test for 'zext <8xi8> to <8xi33>'. Added GISel path testing.

Removed tbl-conversion cases to destination vector element width above 64, due to observed performance regressions. Will move this to a later patch, once we find a fix.

Ran clang-format

Blocked tbl-conversion for destination element size above 64 since only 2 or less destination vector elements can be chosen with each tbl instruction in these cases, making it less beneficial

Added two new test cases for destination vectors of arbitrary lengths

Removed duplicate code by adding function pointers as parameter as advised in the reviews. Added more performance tests using ZExt/Trunc operations in combination with addition operation.

Fixed rebasing error of duplicated tests

Trying to fix patching error again

Trying to fix patching error because of rebasing

Rebased on latest updated zext unit tests

Added tests for multiple back-to-back zext instructions for vectors & rebased on recent commit

Updating labels after rebasing

Trying to patch due to review dependency

Ran clang-format

Variable name changes

Addressed reviewer comments

Rebasing & merging on a recent commit

Trying to fix patching error due to local parent commits

Removed cases where TBL lowering will not be beneficial

Trying to fix rebasing error

Rebasing on parent patch for tests

Removed (8|16)xi16 to (8|16)xi8 conversion because it wasn't showing benefits in instruction count, & additionally adding more instructions to the header. Updated comments.

Updated a comment

Removed case for 'trunc <(8|16)xi16> %x to <(8|16)xi8>' since it was adding more instructions to loop header, while not improving loop instruction count

Rebasing on commit of test cases prior to application of this patch

Updated comments as mentioned in the reviews. Rebased on tests for this change prior to applying this patch.

Added comments

Minor update to comment

In D138059#3935023, @fhahn wrote:

Yeah, it is probably fine now, but testing with a single value also seems to make the test less interesting. You could keep the random initialization and add a version of truncOrZextVecInLoopWithVW8 that disables vectorization to generate comparison data for testing.

Reverted to using random inputs & changed correctness test to compare against same operations with no vectorization

In D138059#3929083, @fhahn wrote:

In D138059#3928627, @paquette wrote:

Why randomized?

! In D138059#3929074, @nilanjana_basu wrote:

Removed randomization in input & combined correctness tests with performance ones. Explicitly added vectorization width for 16 elements since the related patches target this width.

I think the main reason for initializing with random data is to make the benchmarks more robust so the optimizer won't be able to (partly) optimize out our benchmark code?

In D138059#3928627, @paquette wrote:

Why randomized?

Removed randomization in input & combined correctness tests with performance ones. Explicitly added vectorization width for 16 elements since the related patches target this width.

Ran clang-format

Addressed comments by t.p.northover - refactored code to remove redundancy

Patch already exists. This was posted by mistake.

Minor fix to comments

Removed the addition operation to keep only the truncate or zero-extend operation for a more focused performance comparison

All the comments have been addressed in the latest patch.

Removed two test cases whose related patches are not yet available.

Ran clang-format since it was failing in the build report at https://buildkite.com/llvm-project/diff-checks/builds/133184

The automated build tests failed for the previous patch because it was based on a previous commit for a unit test that isn't submitted yet. This patch fixes it by squashing the previous commit, removing the dependency & showing the final update.

Extended the trunc lowering for other types like 16xi64, 16xi16, 8xi16

Extended it to be generic enough for both truncate & zero-extend vector operations

Fixed a mistake where the same test was being ran twice

Made a separate file for testing vector operations for truncate or zero extend. Added tests for truncate of different types of data types, with different vectorization width settings.

Removed redundant code

Removed an unused variable warning

Ran git-clang-format & made minor change to reduce LoC.