[MicroBenchmarks,AArch64] Added correctness test & other performance tests for truncate or zero-extend vector operations

[nilanjana_basu]

Summary

This patch adds a correctness test to check the outcome of vectorized truncate or zero-extend operations in a loop for different vector types.
This patch also adds performance tests for combined operations of truncate/zero-extend and addition.

The goal of this benchmark is to check the impact of AArch64 specific changes in
D133495, D120571, D135229 and D136722.

[paquette]

Why randomized?

[nilanjana_basu]

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

[nilanjana_basu]

In D138059#3928627, @paquette wrote:

Why randomized?

You're right, it was unnecessary. Removed it in the latest patch & combined the correctness tests with the performance ones.

[fhahn]

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?

[nilanjana_basu]

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#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?

I checked that at the IR level the generated code had the relevant trunc & zext instructions, 4 times per function for interleave_count 4. I could also see a performance difference based on the related patches it is meant to test. To be on the safe side, what do you think about adding "benchmark::DoNotOptimize(A)" instead? Or should we prefer reverting to the old form?

[fhahn]

In D138059#3929188, @nilanjana_basu wrote:

I checked that at the IR level the generated code had the relevant trunc & zext instructions, 4 times per function for interleave_count 4. I could also see a performance difference based on the related patches it is meant to test. To be on the safe side, what do you think about adding "benchmark::DoNotOptimize(A)" instead? Or should we prefer reverting to the old form?

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.

[nilanjana_basu]

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

[nilanjana_basu]

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.

Yes, that sounds like a better correctness test. Have updated it.

MicroBenchmarks/LoopVectorization/VectorOperations.cpp

25

Added noinline for ease of verifying the IR to check if this part is not optimized out. Can be removed if deemed unnecessary.

[fhahn]

MicroBenchmarks/LoopVectorization/VectorOperations.cpp

25

it might confuse readers, so its better to remove it I think

26

LLM coding style uses uppercase for variables

68

it would also be good to benchmark a version of the loop without any pragmas.

Also, why fix the VF?

90

It might be better to move this before the main loop so we fail early.

115

we also need versions with different dst types than i8. Same for the src types for zexts

[nilanjana_basu]

Addressed reviewer comments

[nilanjana_basu]

Variable name changes

[nilanjana_basu]

Ran clang-format

[nilanjana_basu]

MicroBenchmarks/LoopVectorization/VectorOperations.cpp

68

Added a version of the benchmark with only vectorization enabled but no other pragmas. Changed the VF to test vectors of length 16 specifically, similar to the VF 8 case, assuming these two are commonly used VFs.

90

Done. Also added the correctness for each version of the benchmarks i.e. for different vectorization configurations. Each configuration should trigger different paths of the trunc/zext lowering & therefore, will be good to be tested for correctness.

[fhahn]

MicroBenchmarks/LoopVectorization/VectorOperations.cpp

78

Is this effectively the same code as benchForTruncOrZextVecInLoopWithVW8 and just calling a different benchmark function? If so, better to make the function an argument to avoid duplication?

[nilanjana_basu]

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.

[fhahn]

LGTM, thanks!

MicroBenchmarks/LoopVectorization/VectorOperations.cpp

108

it might help with readability if there was a newline after each BENCHMARK...