[Arm64] Implement Store Hardware Intrinsic

[echesakov]

Implements Store Arm64 hardware intrinsic

Fixes#24771

Also addresses Brian's feedback and partly Bruce's feedback received on #33461

I decided to have a separate PR for @BruceForstall suggestions concerning finding a proper names for emitDispVectorElemList and other functions.

[Dotnet-GitSync-Bot]

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

[echesakov]

@CarolEidt@TamarChristinaArm@tannergooding PTAL

[echesakov]

Any other feedback here?

[TamarChristinaArm]

Any other feedback here?

So for the single element versions of vst1 and vld1 intrinsics we never generate ST1 and LD1 on little-endian. There we always generate str and ldr since they provide more addressing modes.

e.g.

#include <arm_neon.h>
void foo (int32x4_t v, int32_t *a)
{
return vst1q_s32 (a, v);
}

will generate a str q0, [x0]

For big-endian we do generate the ST1 and LD1 though. This is not to say that this patch is wrong or needs changing. but just a headsup that you have less flexibility. and the single structure single reg intrinsics are the most common ones.

[echesakov]

So for the single element versions of vst1 and vld1 intrinsics we never generate ST1 and LD1 on little-endian. There we always generate str and ldr since they provide more addressing modes.

e.g.

#include <arm_neon.h>
void foo (int32x4_t v, int32_t *a)
{
return vst1q_s32 (a, v);
}

will generate a str q0, [x0]

For big-endian we do generate the ST1 and LD1 though. This is not to say that this patch is wrong or needs changing. but just a headsup that you have less flexibility. and the single structure single reg intrinsics are the most common ones.

Thank you for your feedback @TamarChristinaArm
Is there any performance differences between ld1/st1 and ldr/str in this case?

I am leaning towards keeping ld1/st1 for Load/Store. We can always switch to ldr/str if/when we decide to utilize other addressing modes.

[CarolEidt]

LGTM - nice to see so much of it being table-driven. Most of my time reviewing was reading the manual!

[TamarChristinaArm]

Thank you for your feedback @TamarChristinaArm
Is there any performance differences between ld1/st1 and ldr/str in this case?

I am leaning towards keeping ld1/st1 for Load/Store. We can always switch to ldr/str if/when we decide to utilize other addressing modes.

No there isn't a performance difference in instructions themselves, so that's fine for now.

[echesakov]

So for the single element versions of vst1 and vld1 intrinsics we never generate ST1 and LD1 on little-endian. There we always generate str and ldr since they provide more addressing modes.

e.g.

#include <arm_neon.h>
void foo (int32x4_t v, int32_t *a)
{
return vst1q_s32 (a, v);
}

will generate a str q0, [x0]

For big-endian we do generate the ST1 and LD1 though. This is not to say that this patch is wrong or needs changing. but just a headsup that you have less flexibility. and the single structure single reg intrinsics are the most common ones.

Interestingly, Visual C++ 2019 compiles the following functions

__declspec(noinline)
void foo(int32x4_t v, int32_t* a)
{
returnvst1q_s32(a, v);
}
__declspec(noinline)
void bar(int32x2_t v, int32_t* a)
{
returnvst1_s32(a, v);
}

into

?foo@@YAXT__n128@@PEAH@Z:0000000140001158: 4C007800 st1 {v0.4s},[x0] 000000014000115C: D65F03C0 ret?bar@@YAXT__n64@@PEAH@Z:0000000140001160: 0C007800 st1 {v0.2s},[x0]0000000140001164: D65F03C0 ret

[TamarChristinaArm]

Interestingly, Visual C++ 2019 compiles the following functions

hmm yeah I only checked armclang and gcc :)

[echesakov]

Implements Store Arm64 hardware intrinsic

Fixes#24771

Also addresses Brian's feedback and partly Bruce's feedback received on #33461

I decided to have a separate PR for @BruceForstall suggestions concerning finding a proper names for emitDispVectorElemList and other functions.

[Dotnet-GitSync-Bot]

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

[echesakov]

@CarolEidt@TamarChristinaArm@tannergooding PTAL

[echesakov]

Any other feedback here?

[TamarChristinaArm]

Any other feedback here?

So for the single element versions of vst1 and vld1 intrinsics we never generate ST1 and LD1 on little-endian. There we always generate str and ldr since they provide more addressing modes.

e.g.

#include <arm_neon.h>
void foo (int32x4_t v, int32_t *a)
{
return vst1q_s32 (a, v);
}

will generate a str q0, [x0]

For big-endian we do generate the ST1 and LD1 though. This is not to say that this patch is wrong or needs changing. but just a headsup that you have less flexibility. and the single structure single reg intrinsics are the most common ones.

[echesakov]

So for the single element versions of vst1 and vld1 intrinsics we never generate ST1 and LD1 on little-endian. There we always generate str and ldr since they provide more addressing modes.

e.g.

#include <arm_neon.h>
void foo (int32x4_t v, int32_t *a)
{
return vst1q_s32 (a, v);
}

will generate a str q0, [x0]

For big-endian we do generate the ST1 and LD1 though. This is not to say that this patch is wrong or needs changing. but just a headsup that you have less flexibility. and the single structure single reg intrinsics are the most common ones.

Thank you for your feedback @TamarChristinaArm
Is there any performance differences between ld1/st1 and ldr/str in this case?

I am leaning towards keeping ld1/st1 for Load/Store. We can always switch to ldr/str if/when we decide to utilize other addressing modes.

[CarolEidt]

LGTM - nice to see so much of it being table-driven. Most of my time reviewing was reading the manual!

[TamarChristinaArm]

Thank you for your feedback @TamarChristinaArm
Is there any performance differences between ld1/st1 and ldr/str in this case?

I am leaning towards keeping ld1/st1 for Load/Store. We can always switch to ldr/str if/when we decide to utilize other addressing modes.

No there isn't a performance difference in instructions themselves, so that's fine for now.

[echesakov]

So for the single element versions of vst1 and vld1 intrinsics we never generate ST1 and LD1 on little-endian. There we always generate str and ldr since they provide more addressing modes.

e.g.

#include <arm_neon.h>
void foo (int32x4_t v, int32_t *a)
{
return vst1q_s32 (a, v);
}

will generate a str q0, [x0]

For big-endian we do generate the ST1 and LD1 though. This is not to say that this patch is wrong or needs changing. but just a headsup that you have less flexibility. and the single structure single reg intrinsics are the most common ones.

Interestingly, Visual C++ 2019 compiles the following functions

__declspec(noinline)
void foo(int32x4_t v, int32_t* a)
{
returnvst1q_s32(a, v);
}
__declspec(noinline)
void bar(int32x2_t v, int32_t* a)
{
returnvst1_s32(a, v);
}

into

?foo@@YAXT__n128@@PEAH@Z:0000000140001158: 4C007800 st1 {v0.4s},[x0] 000000014000115C: D65F03C0 ret?bar@@YAXT__n64@@PEAH@Z:0000000140001160: 0C007800 st1 {v0.2s},[x0]0000000140001164: D65F03C0 ret

[TamarChristinaArm]

Interestingly, Visual C++ 2019 compiles the following functions

hmm yeah I only checked armclang and gcc :)

[echesakov]

Implements Store Arm64 hardware intrinsic

Fixes#24771

Also addresses Brian's feedback and partly Bruce's feedback received on #33461

I decided to have a separate PR for @BruceForstall suggestions concerning finding a proper names for emitDispVectorElemList and other functions.

[Dotnet-GitSync-Bot]

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

[echesakov]

@CarolEidt@TamarChristinaArm@tannergooding PTAL

[echesakov]

Any other feedback here?

[TamarChristinaArm]

Any other feedback here?

So for the single element versions of vst1 and vld1 intrinsics we never generate ST1 and LD1 on little-endian. There we always generate str and ldr since they provide more addressing modes.

e.g.

#include <arm_neon.h>
void foo (int32x4_t v, int32_t *a)
{
return vst1q_s32 (a, v);
}

will generate a str q0, [x0]

For big-endian we do generate the ST1 and LD1 though. This is not to say that this patch is wrong or needs changing. but just a headsup that you have less flexibility. and the single structure single reg intrinsics are the most common ones.

[echesakov]

So for the single element versions of vst1 and vld1 intrinsics we never generate ST1 and LD1 on little-endian. There we always generate str and ldr since they provide more addressing modes.

e.g.

#include <arm_neon.h>
void foo (int32x4_t v, int32_t *a)
{
return vst1q_s32 (a, v);
}

will generate a str q0, [x0]

For big-endian we do generate the ST1 and LD1 though. This is not to say that this patch is wrong or needs changing. but just a headsup that you have less flexibility. and the single structure single reg intrinsics are the most common ones.

Thank you for your feedback @TamarChristinaArm
Is there any performance differences between ld1/st1 and ldr/str in this case?

I am leaning towards keeping ld1/st1 for Load/Store. We can always switch to ldr/str if/when we decide to utilize other addressing modes.

[CarolEidt]

LGTM - nice to see so much of it being table-driven. Most of my time reviewing was reading the manual!

[TamarChristinaArm]

Thank you for your feedback @TamarChristinaArm
Is there any performance differences between ld1/st1 and ldr/str in this case?

I am leaning towards keeping ld1/st1 for Load/Store. We can always switch to ldr/str if/when we decide to utilize other addressing modes.

No there isn't a performance difference in instructions themselves, so that's fine for now.

[echesakov]

So for the single element versions of vst1 and vld1 intrinsics we never generate ST1 and LD1 on little-endian. There we always generate str and ldr since they provide more addressing modes.

e.g.

#include <arm_neon.h>
void foo (int32x4_t v, int32_t *a)
{
return vst1q_s32 (a, v);
}

will generate a str q0, [x0]

For big-endian we do generate the ST1 and LD1 though. This is not to say that this patch is wrong or needs changing. but just a headsup that you have less flexibility. and the single structure single reg intrinsics are the most common ones.

Interestingly, Visual C++ 2019 compiles the following functions

__declspec(noinline)
void foo(int32x4_t v, int32_t* a)
{
returnvst1q_s32(a, v);
}
__declspec(noinline)
void bar(int32x2_t v, int32_t* a)
{
returnvst1_s32(a, v);
}

into

?foo@@YAXT__n128@@PEAH@Z:0000000140001158: 4C007800 st1 {v0.4s},[x0] 000000014000115C: D65F03C0 ret?bar@@YAXT__n64@@PEAH@Z:0000000140001160: 0C007800 st1 {v0.2s},[x0]0000000140001164: D65F03C0 ret

[TamarChristinaArm]

Interestingly, Visual C++ 2019 compiles the following functions

hmm yeah I only checked armclang and gcc :)

[echesakov]

Implements Store Arm64 hardware intrinsic

Fixes#24771

Also addresses Brian's feedback and partly Bruce's feedback received on #33461

I decided to have a separate PR for @BruceForstall suggestions concerning finding a proper names for emitDispVectorElemList and other functions.

[Dotnet-GitSync-Bot]

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

[echesakov]

@CarolEidt@TamarChristinaArm@tannergooding PTAL

[echesakov]

Any other feedback here?

[TamarChristinaArm]

Any other feedback here?

So for the single element versions of vst1 and vld1 intrinsics we never generate ST1 and LD1 on little-endian. There we always generate str and ldr since they provide more addressing modes.

e.g.

#include <arm_neon.h>
void foo (int32x4_t v, int32_t *a)
{
return vst1q_s32 (a, v);
}

will generate a str q0, [x0]

For big-endian we do generate the ST1 and LD1 though. This is not to say that this patch is wrong or needs changing. but just a headsup that you have less flexibility. and the single structure single reg intrinsics are the most common ones.

[echesakov]

So for the single element versions of vst1 and vld1 intrinsics we never generate ST1 and LD1 on little-endian. There we always generate str and ldr since they provide more addressing modes.

e.g.

#include <arm_neon.h>
void foo (int32x4_t v, int32_t *a)
{
return vst1q_s32 (a, v);
}

will generate a str q0, [x0]

For big-endian we do generate the ST1 and LD1 though. This is not to say that this patch is wrong or needs changing. but just a headsup that you have less flexibility. and the single structure single reg intrinsics are the most common ones.

Thank you for your feedback @TamarChristinaArm
Is there any performance differences between ld1/st1 and ldr/str in this case?

I am leaning towards keeping ld1/st1 for Load/Store. We can always switch to ldr/str if/when we decide to utilize other addressing modes.

[CarolEidt]

LGTM - nice to see so much of it being table-driven. Most of my time reviewing was reading the manual!

[TamarChristinaArm]

Thank you for your feedback @TamarChristinaArm
Is there any performance differences between ld1/st1 and ldr/str in this case?

I am leaning towards keeping ld1/st1 for Load/Store. We can always switch to ldr/str if/when we decide to utilize other addressing modes.

No there isn't a performance difference in instructions themselves, so that's fine for now.

[echesakov]

So for the single element versions of vst1 and vld1 intrinsics we never generate ST1 and LD1 on little-endian. There we always generate str and ldr since they provide more addressing modes.

e.g.

#include <arm_neon.h>
void foo (int32x4_t v, int32_t *a)
{
return vst1q_s32 (a, v);
}

will generate a str q0, [x0]

For big-endian we do generate the ST1 and LD1 though. This is not to say that this patch is wrong or needs changing. but just a headsup that you have less flexibility. and the single structure single reg intrinsics are the most common ones.

Interestingly, Visual C++ 2019 compiles the following functions

__declspec(noinline)
void foo(int32x4_t v, int32_t* a)
{
returnvst1q_s32(a, v);
}
__declspec(noinline)
void bar(int32x2_t v, int32_t* a)
{
returnvst1_s32(a, v);
}

into

?foo@@YAXT__n128@@PEAH@Z:0000000140001158: 4C007800 st1 {v0.4s},[x0] 000000014000115C: D65F03C0 ret?bar@@YAXT__n64@@PEAH@Z:0000000140001160: 0C007800 st1 {v0.2s},[x0]0000000140001164: D65F03C0 ret

[TamarChristinaArm]

Interestingly, Visual C++ 2019 compiles the following functions

hmm yeah I only checked armclang and gcc :)

[echesakov]

Implements Store Arm64 hardware intrinsic

Fixes#24771

Also addresses Brian's feedback and partly Bruce's feedback received on #33461

I decided to have a separate PR for @BruceForstall suggestions concerning finding a proper names for emitDispVectorElemList and other functions.

[Dotnet-GitSync-Bot]

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

[echesakov]

@CarolEidt@TamarChristinaArm@tannergooding PTAL

[echesakov]

Any other feedback here?

[TamarChristinaArm]

Any other feedback here?

So for the single element versions of vst1 and vld1 intrinsics we never generate ST1 and LD1 on little-endian. There we always generate str and ldr since they provide more addressing modes.

e.g.

#include <arm_neon.h>
void foo (int32x4_t v, int32_t *a)
{
return vst1q_s32 (a, v);
}

will generate a str q0, [x0]

For big-endian we do generate the ST1 and LD1 though. This is not to say that this patch is wrong or needs changing. but just a headsup that you have less flexibility. and the single structure single reg intrinsics are the most common ones.

[echesakov]

So for the single element versions of vst1 and vld1 intrinsics we never generate ST1 and LD1 on little-endian. There we always generate str and ldr since they provide more addressing modes.

e.g.

#include <arm_neon.h>
void foo (int32x4_t v, int32_t *a)
{
return vst1q_s32 (a, v);
}

will generate a str q0, [x0]

For big-endian we do generate the ST1 and LD1 though. This is not to say that this patch is wrong or needs changing. but just a headsup that you have less flexibility. and the single structure single reg intrinsics are the most common ones.

Thank you for your feedback @TamarChristinaArm
Is there any performance differences between ld1/st1 and ldr/str in this case?

I am leaning towards keeping ld1/st1 for Load/Store. We can always switch to ldr/str if/when we decide to utilize other addressing modes.

[CarolEidt]

LGTM - nice to see so much of it being table-driven. Most of my time reviewing was reading the manual!

[TamarChristinaArm]

Thank you for your feedback @TamarChristinaArm
Is there any performance differences between ld1/st1 and ldr/str in this case?

I am leaning towards keeping ld1/st1 for Load/Store. We can always switch to ldr/str if/when we decide to utilize other addressing modes.

No there isn't a performance difference in instructions themselves, so that's fine for now.

[echesakov]

So for the single element versions of vst1 and vld1 intrinsics we never generate ST1 and LD1 on little-endian. There we always generate str and ldr since they provide more addressing modes.

e.g.

#include <arm_neon.h>
void foo (int32x4_t v, int32_t *a)
{
return vst1q_s32 (a, v);
}

will generate a str q0, [x0]

For big-endian we do generate the ST1 and LD1 though. This is not to say that this patch is wrong or needs changing. but just a headsup that you have less flexibility. and the single structure single reg intrinsics are the most common ones.

Interestingly, Visual C++ 2019 compiles the following functions

__declspec(noinline)
void foo(int32x4_t v, int32_t* a)
{
returnvst1q_s32(a, v);
}
__declspec(noinline)
void bar(int32x2_t v, int32_t* a)
{
returnvst1_s32(a, v);
}

into

?foo@@YAXT__n128@@PEAH@Z:0000000140001158: 4C007800 st1 {v0.4s},[x0] 000000014000115C: D65F03C0 ret?bar@@YAXT__n64@@PEAH@Z:0000000140001160: 0C007800 st1 {v0.2s},[x0]0000000140001164: D65F03C0 ret

[TamarChristinaArm]

Interestingly, Visual C++ 2019 compiles the following functions

hmm yeah I only checked armclang and gcc :)

[echesakov]

Implements Store Arm64 hardware intrinsic

Fixes#24771

Also addresses Brian's feedback and partly Bruce's feedback received on #33461

I decided to have a separate PR for @BruceForstall suggestions concerning finding a proper names for emitDispVectorElemList and other functions.

[Dotnet-GitSync-Bot]

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

[echesakov]

@CarolEidt@TamarChristinaArm@tannergooding PTAL

[echesakov]

Any other feedback here?

[TamarChristinaArm]

Any other feedback here?

So for the single element versions of vst1 and vld1 intrinsics we never generate ST1 and LD1 on little-endian. There we always generate str and ldr since they provide more addressing modes.

e.g.

#include <arm_neon.h>
void foo (int32x4_t v, int32_t *a)
{
return vst1q_s32 (a, v);
}

will generate a str q0, [x0]

For big-endian we do generate the ST1 and LD1 though. This is not to say that this patch is wrong or needs changing. but just a headsup that you have less flexibility. and the single structure single reg intrinsics are the most common ones.

[echesakov]

So for the single element versions of vst1 and vld1 intrinsics we never generate ST1 and LD1 on little-endian. There we always generate str and ldr since they provide more addressing modes.

e.g.

#include <arm_neon.h>
void foo (int32x4_t v, int32_t *a)
{
return vst1q_s32 (a, v);
}

will generate a str q0, [x0]

For big-endian we do generate the ST1 and LD1 though. This is not to say that this patch is wrong or needs changing. but just a headsup that you have less flexibility. and the single structure single reg intrinsics are the most common ones.

Thank you for your feedback @TamarChristinaArm
Is there any performance differences between ld1/st1 and ldr/str in this case?

I am leaning towards keeping ld1/st1 for Load/Store. We can always switch to ldr/str if/when we decide to utilize other addressing modes.

[CarolEidt]

LGTM - nice to see so much of it being table-driven. Most of my time reviewing was reading the manual!

[TamarChristinaArm]

Thank you for your feedback @TamarChristinaArm
Is there any performance differences between ld1/st1 and ldr/str in this case?

I am leaning towards keeping ld1/st1 for Load/Store. We can always switch to ldr/str if/when we decide to utilize other addressing modes.

No there isn't a performance difference in instructions themselves, so that's fine for now.

[echesakov]

So for the single element versions of vst1 and vld1 intrinsics we never generate ST1 and LD1 on little-endian. There we always generate str and ldr since they provide more addressing modes.

e.g.

#include <arm_neon.h>
void foo (int32x4_t v, int32_t *a)
{
return vst1q_s32 (a, v);
}

will generate a str q0, [x0]

For big-endian we do generate the ST1 and LD1 though. This is not to say that this patch is wrong or needs changing. but just a headsup that you have less flexibility. and the single structure single reg intrinsics are the most common ones.

Interestingly, Visual C++ 2019 compiles the following functions

__declspec(noinline)
void foo(int32x4_t v, int32_t* a)
{
returnvst1q_s32(a, v);
}
__declspec(noinline)
void bar(int32x2_t v, int32_t* a)
{
returnvst1_s32(a, v);
}

into

?foo@@YAXT__n128@@PEAH@Z:0000000140001158: 4C007800 st1 {v0.4s},[x0] 000000014000115C: D65F03C0 ret?bar@@YAXT__n64@@PEAH@Z:0000000140001160: 0C007800 st1 {v0.2s},[x0]0000000140001164: D65F03C0 ret

[TamarChristinaArm]

Interestingly, Visual C++ 2019 compiles the following functions

hmm yeah I only checked armclang and gcc :)

[echesakov]

Implements Store Arm64 hardware intrinsic

Fixes#24771

Also addresses Brian's feedback and partly Bruce's feedback received on #33461

I decided to have a separate PR for @BruceForstall suggestions concerning finding a proper names for emitDispVectorElemList and other functions.

[Dotnet-GitSync-Bot]

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

[echesakov]

@CarolEidt@TamarChristinaArm@tannergooding PTAL

[echesakov]

Any other feedback here?

[TamarChristinaArm]

Any other feedback here?

So for the single element versions of vst1 and vld1 intrinsics we never generate ST1 and LD1 on little-endian. There we always generate str and ldr since they provide more addressing modes.

e.g.

#include <arm_neon.h>
void foo (int32x4_t v, int32_t *a)
{
return vst1q_s32 (a, v);
}

will generate a str q0, [x0]

For big-endian we do generate the ST1 and LD1 though. This is not to say that this patch is wrong or needs changing. but just a headsup that you have less flexibility. and the single structure single reg intrinsics are the most common ones.

[echesakov]

So for the single element versions of vst1 and vld1 intrinsics we never generate ST1 and LD1 on little-endian. There we always generate str and ldr since they provide more addressing modes.

e.g.

#include <arm_neon.h>
void foo (int32x4_t v, int32_t *a)
{
return vst1q_s32 (a, v);
}

will generate a str q0, [x0]

For big-endian we do generate the ST1 and LD1 though. This is not to say that this patch is wrong or needs changing. but just a headsup that you have less flexibility. and the single structure single reg intrinsics are the most common ones.

Thank you for your feedback @TamarChristinaArm
Is there any performance differences between ld1/st1 and ldr/str in this case?

I am leaning towards keeping ld1/st1 for Load/Store. We can always switch to ldr/str if/when we decide to utilize other addressing modes.

[CarolEidt]

LGTM - nice to see so much of it being table-driven. Most of my time reviewing was reading the manual!

[TamarChristinaArm]

Thank you for your feedback @TamarChristinaArm
Is there any performance differences between ld1/st1 and ldr/str in this case?

I am leaning towards keeping ld1/st1 for Load/Store. We can always switch to ldr/str if/when we decide to utilize other addressing modes.

No there isn't a performance difference in instructions themselves, so that's fine for now.

[echesakov]

So for the single element versions of vst1 and vld1 intrinsics we never generate ST1 and LD1 on little-endian. There we always generate str and ldr since they provide more addressing modes.

e.g.

#include <arm_neon.h>
void foo (int32x4_t v, int32_t *a)
{
return vst1q_s32 (a, v);
}

will generate a str q0, [x0]

For big-endian we do generate the ST1 and LD1 though. This is not to say that this patch is wrong or needs changing. but just a headsup that you have less flexibility. and the single structure single reg intrinsics are the most common ones.

Interestingly, Visual C++ 2019 compiles the following functions

__declspec(noinline)
void foo(int32x4_t v, int32_t* a)
{
returnvst1q_s32(a, v);
}
__declspec(noinline)
void bar(int32x2_t v, int32_t* a)
{
returnvst1_s32(a, v);
}

into

?foo@@YAXT__n128@@PEAH@Z:0000000140001158: 4C007800 st1 {v0.4s},[x0] 000000014000115C: D65F03C0 ret?bar@@YAXT__n64@@PEAH@Z:0000000140001160: 0C007800 st1 {v0.2s},[x0]0000000140001164: D65F03C0 ret

[TamarChristinaArm]

Interestingly, Visual C++ 2019 compiles the following functions

hmm yeah I only checked armclang and gcc :)

[echesakov]

Implements Store Arm64 hardware intrinsic

Fixes#24771

Also addresses Brian's feedback and partly Bruce's feedback received on #33461

I decided to have a separate PR for @BruceForstall suggestions concerning finding a proper names for emitDispVectorElemList and other functions.

[Dotnet-GitSync-Bot]

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

[echesakov]

@CarolEidt@TamarChristinaArm@tannergooding PTAL

[echesakov]

Any other feedback here?

[TamarChristinaArm]

Any other feedback here?

So for the single element versions of vst1 and vld1 intrinsics we never generate ST1 and LD1 on little-endian. There we always generate str and ldr since they provide more addressing modes.

e.g.

#include <arm_neon.h>
void foo (int32x4_t v, int32_t *a)
{
return vst1q_s32 (a, v);
}

will generate a str q0, [x0]

For big-endian we do generate the ST1 and LD1 though. This is not to say that this patch is wrong or needs changing. but just a headsup that you have less flexibility. and the single structure single reg intrinsics are the most common ones.

[echesakov]

So for the single element versions of vst1 and vld1 intrinsics we never generate ST1 and LD1 on little-endian. There we always generate str and ldr since they provide more addressing modes.

e.g.

#include <arm_neon.h>
void foo (int32x4_t v, int32_t *a)
{
return vst1q_s32 (a, v);
}

will generate a str q0, [x0]

For big-endian we do generate the ST1 and LD1 though. This is not to say that this patch is wrong or needs changing. but just a headsup that you have less flexibility. and the single structure single reg intrinsics are the most common ones.

Thank you for your feedback @TamarChristinaArm
Is there any performance differences between ld1/st1 and ldr/str in this case?

I am leaning towards keeping ld1/st1 for Load/Store. We can always switch to ldr/str if/when we decide to utilize other addressing modes.

[CarolEidt]

LGTM - nice to see so much of it being table-driven. Most of my time reviewing was reading the manual!

[TamarChristinaArm]

Thank you for your feedback @TamarChristinaArm
Is there any performance differences between ld1/st1 and ldr/str in this case?

I am leaning towards keeping ld1/st1 for Load/Store. We can always switch to ldr/str if/when we decide to utilize other addressing modes.

No there isn't a performance difference in instructions themselves, so that's fine for now.

[echesakov]

So for the single element versions of vst1 and vld1 intrinsics we never generate ST1 and LD1 on little-endian. There we always generate str and ldr since they provide more addressing modes.

e.g.

#include <arm_neon.h>
void foo (int32x4_t v, int32_t *a)
{
return vst1q_s32 (a, v);
}

will generate a str q0, [x0]

For big-endian we do generate the ST1 and LD1 though. This is not to say that this patch is wrong or needs changing. but just a headsup that you have less flexibility. and the single structure single reg intrinsics are the most common ones.

Interestingly, Visual C++ 2019 compiles the following functions

__declspec(noinline)
void foo(int32x4_t v, int32_t* a)
{
returnvst1q_s32(a, v);
}
__declspec(noinline)
void bar(int32x2_t v, int32_t* a)
{
returnvst1_s32(a, v);
}

into

?foo@@YAXT__n128@@PEAH@Z:0000000140001158: 4C007800 st1 {v0.4s},[x0] 000000014000115C: D65F03C0 ret?bar@@YAXT__n64@@PEAH@Z:0000000140001160: 0C007800 st1 {v0.2s},[x0]0000000140001164: D65F03C0 ret

[TamarChristinaArm]

Interestingly, Visual C++ 2019 compiles the following functions

hmm yeah I only checked armclang and gcc :)