ARM64-SVE: gathervector by a74nh · Pull Request #103159 · dotnet/runtime

a74nh · 2024-06-07T11:08:39Z

No description provided.

ghost · 2024-06-07T11:08:45Z

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, 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.

ghost · 2024-06-07T11:08:46Z

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, 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.

dotnet-policy-service · 2024-06-07T11:09:17Z

Tagging subscribers to this area: @dotnet/area-system-runtime-intrinsics
See info in area-owners.md if you want to be subscribed.

a74nh · 2024-06-07T11:14:24Z

This is working.

However, 3 tests are commented out. These are the ones with Vector<uint> for the address. Eg:

publicstaticunsafeVector<float>GatherVector(Vector<float>mask,Vector<uint>addresses);

I don't think this works for C#.

Each address is a 32bit value. Sve is only for Arm64.

@tannergooding : thoughts?

a74nh · 2024-06-07T11:53:26Z

@dotnet/arm64-contrib @kunalspathak

a74nh · 2024-06-07T13:01:37Z

Stress tests results

Looks like two errors:

Incorrect values loaded, probably due to incorrect predicates (the known issue?)
~~2) Segfault due to invalid memory load, always in GatherVector_Indices_float_int. Investigating this.~~

a74nh · 2024-06-07T13:19:40Z

Stress tests results
Looks like two errors:
Incorrect values loaded, probably due to incorrect predicates (the known issue?)
Segfault due to invalid memory load, always in GatherVector_Indices_float_int. Investigating this.

Scratch error 2 - those were due to running on a 256bit machine (and therefore issues around storing to the stack).
So just error 1, which looks like the known predicate issue.

kunalspathak

looks good overall. added some comments.

kunalspathak · 2024-06-07T13:44:10Z

+
+ if (auxSize == EA_8BYTE)
+ {
+ opt = varTypeIsUnsigned(auxType) ? INS_OPTS_SCALABLE_D_UXTW : INS_OPTS_SCALABLE_D_SXTW;


From the summary docs, we are emitting LD1D Zresult.D, Pg/Z, [Xbase, Zindices.D, LSL #3], which does not take xs field, so we do not have to embed UXTW or SXTW bit, right?

From the summary docs, we are emitting LD1D Zresult.D, Pg/Z, [Xbase, Zindices.D, LSL #3],
Correct
which does not take xs field, so we do not have to embed UXTW or SXTW bit, right?
Removing this, I get an asset (in emitarm64sve.cpp:6441). Looks like emit is expecting this field. I'll have to debug it a little more. There are a lot of different loads and I don't want to break any of them.

so you are saying that although we pass the *XTW flag, we are not using it in for this instruction, although the code path flows through the emitarm64sve.cpp that you mentioned?

Looks like it's using the flag to make a decision to decide on the correct encoding. Then doesn't use it later. Probably just needs a fix in emit.

Probably just needs a fix in emit.
Did you fix it in this PR?

Addressing modes now fixed. There are three variants for "address with vector of offsets":
Vector<64bit> GatherVector(Vector<64bit> mask, 64bit* address, Vector<64bit> indices) -> LD1D Zresult.D, Pg/Z, [Xbase, Zindices.D, LSL #3]
Vector<32bit> GatherVector(Vector<32bit> mask, 32bit* address, Vector<signed32bit> indices) -> LD1W Zresult.S, Pg/Z, [Xbase, Zindices.S, SXTW #2]
Vector<32bit> GatherVector(Vector<32bit> mask, 32bit* address, Vector<unsigned32bit> indices) -> LD1W Zresult.S, Pg/Z, [Xbase, Zindices.S, UXTW #2]
Codegen now picks the correct ones

tannergooding · 2024-06-07T17:28:07Z

@tannergooding : thoughts?

If there is an encoding that allows this parameter to be Vector<uint> then we should expose the corresponding managed API.

Having trouble following the SVE docs here since there are like 8+ different instructions called LD1D, some of which are for contiguous and some of which are for gather....

But it looks like LD1D (scalar plus vector) only allows the indexes to be 32-bit

Gather load of doublewords to active elements of a vector register from memory addresses generated by a 64-bit scalar base plus vector index. The index values are optionally first sign or zero-extended from 32 to 64 bits and then optionally multiplied by 8. Inactive elements will not cause a read from Device memory or signal faults, and are set to zero in the destination vector.

In all cases, it looks like esize is 64 and msize is 64. It's only offs_size that is 32 or 64

a74nh · 2024-06-10T15:38:26Z

@tannergooding : thoughts?
If there is an encoding that allows this parameter to be Vector<uint> then we should expose the corresponding managed API.
Having trouble following the SVE docs here since there are like 8+ different instructions called LD1D, some of which are for contiguous and some of which are for gather....
But it looks like LD1D (scalar plus vector) only allows the indexes to be 32-bit
Gather load of doublewords to active elements of a vector register from memory addresses generated by a 64-bit scalar base plus vector index. The index values are optionally first sign or zero-extended from 32 to 64 bits and then optionally multiplied by 8. Inactive elements will not cause a read from Device memory or signal faults, and are set to zero in the destination vector.
In all cases, it looks like esize is 64 and msize is 64. It's only offs_size that is 32 or 64

This is for:

 /// <summary>
/// svint32_t svld1_gather[_u32base]_s32(svbool_t pg, svuint32_t bases)
/// LD1W Zresult.S, Pg/Z, [Zbases.S, #0]
/// </summary>
public static unsafe Vector<int> GatherVector(Vector<int> mask, Vector<uint> addresses) => GatherVector(mask, addresses);

Which maps to Gather load unsigned words to vector (immediate index) with an immediate value of 0.
The addresses are 32bit (with esize = 32) and then zero extended to 64bits.

Unless we can the address of a C# object to fit into a 32bit address I can't see this working.

tannergooding · 2024-06-10T16:22:51Z

Unless we can the address of a C# object to fit into a 32bit address I can't see this working.

I don't see the issue. This doesn't have anything to do with objects, but rather truncated pointers. That is, Vector<T> addresses represents the pointers into fixed memory where that address is in the first 4GB of the address space.

While it isn't usable for an arbitrary T*, it can still be used for reading from explicitly mapped memory such as you might have in more advanced user scenarios. -- The same scenarios you'd use it for in C/C++

a74nh · 2024-06-10T19:26:50Z

Unless we can the address of a C# object to fit into a 32bit address I can't see this working.
I don't see the issue. This doesn't have anything to do with objects, but rather truncated pointers. That is, Vector<T> addresses represents the pointers into fixed memory where that address is in the first 4GB of the address space.
While it isn't usable for an arbitrary T*, it can still be used for reading from explicitly mapped memory such as you might have in more advanced user scenarios. -- The same scenarios you'd use it for in C/C++

Ok, that's fair, I wasn't sure it was possible to restrict memory in that way in C#.

Do you have any pointers on how I might construct a blob of memory the first 4GB in C# for the test case?

tannergooding · 2024-06-10T19:36:41Z

You'd need to use an API like VirtualAlloc on Windows, such as via P/Invoke: https://learn.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualalloc. An equivalent, such as mmap, would need to be used on Unix.

It should be roughly equivalent to how you'd test the same functionality in C/C++

kunalspathak · 2024-06-10T20:45:00Z

You'd need to use an API like VirtualAlloc on Windows, such as via P/Invoke: https://learn.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualalloc. An equivalent, such as mmap, would need to be used on Unix.
It should be roughly equivalent to how you'd test the same functionality in C/C++

I don't want to spend too much time on writing test for this scenario, given that we have around 40% APIs to complete in .NET 9. For now, I will just comment out exposing these APIs and come back to it once we have some cycles.

a74nh · 2024-06-11T10:19:29Z

I don't want to spend too much time on writing test for this scenario, given that we have around 40% APIs to complete in .NET 9. For now, I will just comment out exposing these APIs and come back to it once we have some cycles.

Agreed - gather vector is likely to be infrequently used. Use of variants with a 32bit address will be much rarer.

I've removed them from the external API files, but left them commented out in internal files. That should make it easier to revive later.

a74nh · 2024-06-11T10:52:38Z

Stress results.
Looks like all the failures are known predicate issues during Stress 2 + Stress Regs 1.

kunalspathak

LGTM, after we put back the 32-bit address APIs with a comment pointing to #103297

kunalspathak

LGTM. Thanks!

kunalspathak · 2024-06-12T16:37:38Z

/ba-g failures are because of #103354

a74nh · 2024-06-07T11:08:39Z

No description provided.

ghost · 2024-06-07T11:08:45Z

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, 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.

ghost · 2024-06-07T11:08:46Z

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, 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.

dotnet-policy-service · 2024-06-07T11:09:17Z

Tagging subscribers to this area: @dotnet/area-system-runtime-intrinsics
See info in area-owners.md if you want to be subscribed.

a74nh · 2024-06-07T11:14:24Z

This is working.

However, 3 tests are commented out. These are the ones with Vector<uint> for the address. Eg:

publicstaticunsafeVector<float>GatherVector(Vector<float>mask,Vector<uint>addresses);

I don't think this works for C#.

Each address is a 32bit value. Sve is only for Arm64.

@tannergooding : thoughts?

a74nh · 2024-06-07T11:53:26Z

@dotnet/arm64-contrib @kunalspathak

a74nh · 2024-06-07T13:01:37Z

Stress tests results

Looks like two errors:

Incorrect values loaded, probably due to incorrect predicates (the known issue?)
~~2) Segfault due to invalid memory load, always in GatherVector_Indices_float_int. Investigating this.~~

a74nh · 2024-06-07T13:19:40Z

Stress tests results
Looks like two errors:
Incorrect values loaded, probably due to incorrect predicates (the known issue?)
Segfault due to invalid memory load, always in GatherVector_Indices_float_int. Investigating this.

Scratch error 2 - those were due to running on a 256bit machine (and therefore issues around storing to the stack).
So just error 1, which looks like the known predicate issue.

kunalspathak

looks good overall. added some comments.

kunalspathak · 2024-06-07T13:44:10Z

+
+ if (auxSize == EA_8BYTE)
+ {
+ opt = varTypeIsUnsigned(auxType) ? INS_OPTS_SCALABLE_D_UXTW : INS_OPTS_SCALABLE_D_SXTW;


From the summary docs, we are emitting LD1D Zresult.D, Pg/Z, [Xbase, Zindices.D, LSL #3], which does not take xs field, so we do not have to embed UXTW or SXTW bit, right?

From the summary docs, we are emitting LD1D Zresult.D, Pg/Z, [Xbase, Zindices.D, LSL #3],
Correct
which does not take xs field, so we do not have to embed UXTW or SXTW bit, right?
Removing this, I get an asset (in emitarm64sve.cpp:6441). Looks like emit is expecting this field. I'll have to debug it a little more. There are a lot of different loads and I don't want to break any of them.

so you are saying that although we pass the *XTW flag, we are not using it in for this instruction, although the code path flows through the emitarm64sve.cpp that you mentioned?

Looks like it's using the flag to make a decision to decide on the correct encoding. Then doesn't use it later. Probably just needs a fix in emit.

Probably just needs a fix in emit.
Did you fix it in this PR?

Addressing modes now fixed. There are three variants for "address with vector of offsets":
Vector<64bit> GatherVector(Vector<64bit> mask, 64bit* address, Vector<64bit> indices) -> LD1D Zresult.D, Pg/Z, [Xbase, Zindices.D, LSL #3]
Vector<32bit> GatherVector(Vector<32bit> mask, 32bit* address, Vector<signed32bit> indices) -> LD1W Zresult.S, Pg/Z, [Xbase, Zindices.S, SXTW #2]
Vector<32bit> GatherVector(Vector<32bit> mask, 32bit* address, Vector<unsigned32bit> indices) -> LD1W Zresult.S, Pg/Z, [Xbase, Zindices.S, UXTW #2]
Codegen now picks the correct ones

tannergooding · 2024-06-07T17:28:07Z

@tannergooding : thoughts?

If there is an encoding that allows this parameter to be Vector<uint> then we should expose the corresponding managed API.

Having trouble following the SVE docs here since there are like 8+ different instructions called LD1D, some of which are for contiguous and some of which are for gather....

But it looks like LD1D (scalar plus vector) only allows the indexes to be 32-bit

Gather load of doublewords to active elements of a vector register from memory addresses generated by a 64-bit scalar base plus vector index. The index values are optionally first sign or zero-extended from 32 to 64 bits and then optionally multiplied by 8. Inactive elements will not cause a read from Device memory or signal faults, and are set to zero in the destination vector.

In all cases, it looks like esize is 64 and msize is 64. It's only offs_size that is 32 or 64

a74nh · 2024-06-10T15:38:26Z

@tannergooding : thoughts?
If there is an encoding that allows this parameter to be Vector<uint> then we should expose the corresponding managed API.
Having trouble following the SVE docs here since there are like 8+ different instructions called LD1D, some of which are for contiguous and some of which are for gather....
But it looks like LD1D (scalar plus vector) only allows the indexes to be 32-bit
Gather load of doublewords to active elements of a vector register from memory addresses generated by a 64-bit scalar base plus vector index. The index values are optionally first sign or zero-extended from 32 to 64 bits and then optionally multiplied by 8. Inactive elements will not cause a read from Device memory or signal faults, and are set to zero in the destination vector.
In all cases, it looks like esize is 64 and msize is 64. It's only offs_size that is 32 or 64

This is for:

 /// <summary>
/// svint32_t svld1_gather[_u32base]_s32(svbool_t pg, svuint32_t bases)
/// LD1W Zresult.S, Pg/Z, [Zbases.S, #0]
/// </summary>
public static unsafe Vector<int> GatherVector(Vector<int> mask, Vector<uint> addresses) => GatherVector(mask, addresses);

Which maps to Gather load unsigned words to vector (immediate index) with an immediate value of 0.
The addresses are 32bit (with esize = 32) and then zero extended to 64bits.

Unless we can the address of a C# object to fit into a 32bit address I can't see this working.

tannergooding · 2024-06-10T16:22:51Z

Unless we can the address of a C# object to fit into a 32bit address I can't see this working.

I don't see the issue. This doesn't have anything to do with objects, but rather truncated pointers. That is, Vector<T> addresses represents the pointers into fixed memory where that address is in the first 4GB of the address space.

While it isn't usable for an arbitrary T*, it can still be used for reading from explicitly mapped memory such as you might have in more advanced user scenarios. -- The same scenarios you'd use it for in C/C++

a74nh · 2024-06-10T19:26:50Z

Unless we can the address of a C# object to fit into a 32bit address I can't see this working.
I don't see the issue. This doesn't have anything to do with objects, but rather truncated pointers. That is, Vector<T> addresses represents the pointers into fixed memory where that address is in the first 4GB of the address space.
While it isn't usable for an arbitrary T*, it can still be used for reading from explicitly mapped memory such as you might have in more advanced user scenarios. -- The same scenarios you'd use it for in C/C++

Ok, that's fair, I wasn't sure it was possible to restrict memory in that way in C#.

Do you have any pointers on how I might construct a blob of memory the first 4GB in C# for the test case?

tannergooding · 2024-06-10T19:36:41Z

You'd need to use an API like VirtualAlloc on Windows, such as via P/Invoke: https://learn.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualalloc. An equivalent, such as mmap, would need to be used on Unix.

It should be roughly equivalent to how you'd test the same functionality in C/C++

kunalspathak · 2024-06-10T20:45:00Z

You'd need to use an API like VirtualAlloc on Windows, such as via P/Invoke: https://learn.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualalloc. An equivalent, such as mmap, would need to be used on Unix.
It should be roughly equivalent to how you'd test the same functionality in C/C++

I don't want to spend too much time on writing test for this scenario, given that we have around 40% APIs to complete in .NET 9. For now, I will just comment out exposing these APIs and come back to it once we have some cycles.

a74nh · 2024-06-11T10:19:29Z

I don't want to spend too much time on writing test for this scenario, given that we have around 40% APIs to complete in .NET 9. For now, I will just comment out exposing these APIs and come back to it once we have some cycles.

Agreed - gather vector is likely to be infrequently used. Use of variants with a 32bit address will be much rarer.

I've removed them from the external API files, but left them commented out in internal files. That should make it easier to revive later.

a74nh · 2024-06-11T10:52:38Z

Stress results.
Looks like all the failures are known predicate issues during Stress 2 + Stress Regs 1.

kunalspathak

LGTM, after we put back the 32-bit address APIs with a comment pointing to #103297

kunalspathak

LGTM. Thanks!

kunalspathak · 2024-06-12T16:37:38Z

/ba-g failures are because of #103354

a74nh · 2024-06-07T11:08:39Z

No description provided.

ghost · 2024-06-07T11:08:45Z

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, 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.

ghost · 2024-06-07T11:08:46Z

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, 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.

dotnet-policy-service · 2024-06-07T11:09:17Z

Tagging subscribers to this area: @dotnet/area-system-runtime-intrinsics
See info in area-owners.md if you want to be subscribed.

a74nh · 2024-06-07T11:14:24Z

This is working.

However, 3 tests are commented out. These are the ones with Vector<uint> for the address. Eg:

publicstaticunsafeVector<float>GatherVector(Vector<float>mask,Vector<uint>addresses);

I don't think this works for C#.

Each address is a 32bit value. Sve is only for Arm64.

@tannergooding : thoughts?

a74nh · 2024-06-07T11:53:26Z

@dotnet/arm64-contrib @kunalspathak

a74nh · 2024-06-07T13:01:37Z

Stress tests results

Looks like two errors:

Incorrect values loaded, probably due to incorrect predicates (the known issue?)
~~2) Segfault due to invalid memory load, always in GatherVector_Indices_float_int. Investigating this.~~

a74nh · 2024-06-07T13:19:40Z

Stress tests results
Looks like two errors:
Incorrect values loaded, probably due to incorrect predicates (the known issue?)
Segfault due to invalid memory load, always in GatherVector_Indices_float_int. Investigating this.

Scratch error 2 - those were due to running on a 256bit machine (and therefore issues around storing to the stack).
So just error 1, which looks like the known predicate issue.

kunalspathak

looks good overall. added some comments.

kunalspathak · 2024-06-07T13:44:10Z

+
+ if (auxSize == EA_8BYTE)
+ {
+ opt = varTypeIsUnsigned(auxType) ? INS_OPTS_SCALABLE_D_UXTW : INS_OPTS_SCALABLE_D_SXTW;


From the summary docs, we are emitting LD1D Zresult.D, Pg/Z, [Xbase, Zindices.D, LSL #3], which does not take xs field, so we do not have to embed UXTW or SXTW bit, right?

From the summary docs, we are emitting LD1D Zresult.D, Pg/Z, [Xbase, Zindices.D, LSL #3],
Correct
which does not take xs field, so we do not have to embed UXTW or SXTW bit, right?
Removing this, I get an asset (in emitarm64sve.cpp:6441). Looks like emit is expecting this field. I'll have to debug it a little more. There are a lot of different loads and I don't want to break any of them.

so you are saying that although we pass the *XTW flag, we are not using it in for this instruction, although the code path flows through the emitarm64sve.cpp that you mentioned?

Looks like it's using the flag to make a decision to decide on the correct encoding. Then doesn't use it later. Probably just needs a fix in emit.

Probably just needs a fix in emit.
Did you fix it in this PR?

Addressing modes now fixed. There are three variants for "address with vector of offsets":
Vector<64bit> GatherVector(Vector<64bit> mask, 64bit* address, Vector<64bit> indices) -> LD1D Zresult.D, Pg/Z, [Xbase, Zindices.D, LSL #3]
Vector<32bit> GatherVector(Vector<32bit> mask, 32bit* address, Vector<signed32bit> indices) -> LD1W Zresult.S, Pg/Z, [Xbase, Zindices.S, SXTW #2]
Vector<32bit> GatherVector(Vector<32bit> mask, 32bit* address, Vector<unsigned32bit> indices) -> LD1W Zresult.S, Pg/Z, [Xbase, Zindices.S, UXTW #2]
Codegen now picks the correct ones

tannergooding · 2024-06-07T17:28:07Z

@tannergooding : thoughts?

If there is an encoding that allows this parameter to be Vector<uint> then we should expose the corresponding managed API.

Having trouble following the SVE docs here since there are like 8+ different instructions called LD1D, some of which are for contiguous and some of which are for gather....

But it looks like LD1D (scalar plus vector) only allows the indexes to be 32-bit

Gather load of doublewords to active elements of a vector register from memory addresses generated by a 64-bit scalar base plus vector index. The index values are optionally first sign or zero-extended from 32 to 64 bits and then optionally multiplied by 8. Inactive elements will not cause a read from Device memory or signal faults, and are set to zero in the destination vector.

In all cases, it looks like esize is 64 and msize is 64. It's only offs_size that is 32 or 64

a74nh · 2024-06-10T15:38:26Z

@tannergooding : thoughts?
If there is an encoding that allows this parameter to be Vector<uint> then we should expose the corresponding managed API.
Having trouble following the SVE docs here since there are like 8+ different instructions called LD1D, some of which are for contiguous and some of which are for gather....
But it looks like LD1D (scalar plus vector) only allows the indexes to be 32-bit
Gather load of doublewords to active elements of a vector register from memory addresses generated by a 64-bit scalar base plus vector index. The index values are optionally first sign or zero-extended from 32 to 64 bits and then optionally multiplied by 8. Inactive elements will not cause a read from Device memory or signal faults, and are set to zero in the destination vector.
In all cases, it looks like esize is 64 and msize is 64. It's only offs_size that is 32 or 64

This is for:

 /// <summary>
/// svint32_t svld1_gather[_u32base]_s32(svbool_t pg, svuint32_t bases)
/// LD1W Zresult.S, Pg/Z, [Zbases.S, #0]
/// </summary>
public static unsafe Vector<int> GatherVector(Vector<int> mask, Vector<uint> addresses) => GatherVector(mask, addresses);

Which maps to Gather load unsigned words to vector (immediate index) with an immediate value of 0.
The addresses are 32bit (with esize = 32) and then zero extended to 64bits.

Unless we can the address of a C# object to fit into a 32bit address I can't see this working.

tannergooding · 2024-06-10T16:22:51Z

Unless we can the address of a C# object to fit into a 32bit address I can't see this working.

I don't see the issue. This doesn't have anything to do with objects, but rather truncated pointers. That is, Vector<T> addresses represents the pointers into fixed memory where that address is in the first 4GB of the address space.

While it isn't usable for an arbitrary T*, it can still be used for reading from explicitly mapped memory such as you might have in more advanced user scenarios. -- The same scenarios you'd use it for in C/C++

a74nh · 2024-06-10T19:26:50Z

Unless we can the address of a C# object to fit into a 32bit address I can't see this working.
I don't see the issue. This doesn't have anything to do with objects, but rather truncated pointers. That is, Vector<T> addresses represents the pointers into fixed memory where that address is in the first 4GB of the address space.
While it isn't usable for an arbitrary T*, it can still be used for reading from explicitly mapped memory such as you might have in more advanced user scenarios. -- The same scenarios you'd use it for in C/C++

Ok, that's fair, I wasn't sure it was possible to restrict memory in that way in C#.

Do you have any pointers on how I might construct a blob of memory the first 4GB in C# for the test case?

tannergooding · 2024-06-10T19:36:41Z

You'd need to use an API like VirtualAlloc on Windows, such as via P/Invoke: https://learn.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualalloc. An equivalent, such as mmap, would need to be used on Unix.

It should be roughly equivalent to how you'd test the same functionality in C/C++

kunalspathak · 2024-06-10T20:45:00Z

You'd need to use an API like VirtualAlloc on Windows, such as via P/Invoke: https://learn.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualalloc. An equivalent, such as mmap, would need to be used on Unix.
It should be roughly equivalent to how you'd test the same functionality in C/C++

I don't want to spend too much time on writing test for this scenario, given that we have around 40% APIs to complete in .NET 9. For now, I will just comment out exposing these APIs and come back to it once we have some cycles.

a74nh · 2024-06-11T10:19:29Z

I don't want to spend too much time on writing test for this scenario, given that we have around 40% APIs to complete in .NET 9. For now, I will just comment out exposing these APIs and come back to it once we have some cycles.

Agreed - gather vector is likely to be infrequently used. Use of variants with a 32bit address will be much rarer.

I've removed them from the external API files, but left them commented out in internal files. That should make it easier to revive later.

a74nh · 2024-06-11T10:52:38Z

Stress results.
Looks like all the failures are known predicate issues during Stress 2 + Stress Regs 1.

kunalspathak

LGTM, after we put back the 32-bit address APIs with a comment pointing to #103297

kunalspathak

LGTM. Thanks!

kunalspathak · 2024-06-12T16:37:38Z

/ba-g failures are because of #103354

a74nh · 2024-06-07T11:08:39Z

No description provided.

ghost · 2024-06-07T11:08:45Z

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, 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.

ghost · 2024-06-07T11:08:46Z

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, 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.

dotnet-policy-service · 2024-06-07T11:09:17Z

Tagging subscribers to this area: @dotnet/area-system-runtime-intrinsics
See info in area-owners.md if you want to be subscribed.

a74nh · 2024-06-07T11:14:24Z

This is working.

However, 3 tests are commented out. These are the ones with Vector<uint> for the address. Eg:

publicstaticunsafeVector<float>GatherVector(Vector<float>mask,Vector<uint>addresses);

I don't think this works for C#.

Each address is a 32bit value. Sve is only for Arm64.

@tannergooding : thoughts?

a74nh · 2024-06-07T11:53:26Z

@dotnet/arm64-contrib @kunalspathak

a74nh · 2024-06-07T13:01:37Z

Stress tests results

Looks like two errors:

Incorrect values loaded, probably due to incorrect predicates (the known issue?)
~~2) Segfault due to invalid memory load, always in GatherVector_Indices_float_int. Investigating this.~~

a74nh · 2024-06-07T13:19:40Z

Stress tests results
Looks like two errors:
Incorrect values loaded, probably due to incorrect predicates (the known issue?)
Segfault due to invalid memory load, always in GatherVector_Indices_float_int. Investigating this.

Scratch error 2 - those were due to running on a 256bit machine (and therefore issues around storing to the stack).
So just error 1, which looks like the known predicate issue.

kunalspathak

looks good overall. added some comments.

kunalspathak · 2024-06-07T13:44:10Z

+
+ if (auxSize == EA_8BYTE)
+ {
+ opt = varTypeIsUnsigned(auxType) ? INS_OPTS_SCALABLE_D_UXTW : INS_OPTS_SCALABLE_D_SXTW;


From the summary docs, we are emitting LD1D Zresult.D, Pg/Z, [Xbase, Zindices.D, LSL #3], which does not take xs field, so we do not have to embed UXTW or SXTW bit, right?

From the summary docs, we are emitting LD1D Zresult.D, Pg/Z, [Xbase, Zindices.D, LSL #3],
Correct
which does not take xs field, so we do not have to embed UXTW or SXTW bit, right?
Removing this, I get an asset (in emitarm64sve.cpp:6441). Looks like emit is expecting this field. I'll have to debug it a little more. There are a lot of different loads and I don't want to break any of them.

so you are saying that although we pass the *XTW flag, we are not using it in for this instruction, although the code path flows through the emitarm64sve.cpp that you mentioned?

Looks like it's using the flag to make a decision to decide on the correct encoding. Then doesn't use it later. Probably just needs a fix in emit.

Probably just needs a fix in emit.
Did you fix it in this PR?

Addressing modes now fixed. There are three variants for "address with vector of offsets":
Vector<64bit> GatherVector(Vector<64bit> mask, 64bit* address, Vector<64bit> indices) -> LD1D Zresult.D, Pg/Z, [Xbase, Zindices.D, LSL #3]
Vector<32bit> GatherVector(Vector<32bit> mask, 32bit* address, Vector<signed32bit> indices) -> LD1W Zresult.S, Pg/Z, [Xbase, Zindices.S, SXTW #2]
Vector<32bit> GatherVector(Vector<32bit> mask, 32bit* address, Vector<unsigned32bit> indices) -> LD1W Zresult.S, Pg/Z, [Xbase, Zindices.S, UXTW #2]
Codegen now picks the correct ones

tannergooding · 2024-06-07T17:28:07Z

@tannergooding : thoughts?

If there is an encoding that allows this parameter to be Vector<uint> then we should expose the corresponding managed API.

Having trouble following the SVE docs here since there are like 8+ different instructions called LD1D, some of which are for contiguous and some of which are for gather....

But it looks like LD1D (scalar plus vector) only allows the indexes to be 32-bit

Gather load of doublewords to active elements of a vector register from memory addresses generated by a 64-bit scalar base plus vector index. The index values are optionally first sign or zero-extended from 32 to 64 bits and then optionally multiplied by 8. Inactive elements will not cause a read from Device memory or signal faults, and are set to zero in the destination vector.

In all cases, it looks like esize is 64 and msize is 64. It's only offs_size that is 32 or 64

a74nh · 2024-06-10T15:38:26Z

@tannergooding : thoughts?
If there is an encoding that allows this parameter to be Vector<uint> then we should expose the corresponding managed API.
Having trouble following the SVE docs here since there are like 8+ different instructions called LD1D, some of which are for contiguous and some of which are for gather....
But it looks like LD1D (scalar plus vector) only allows the indexes to be 32-bit
Gather load of doublewords to active elements of a vector register from memory addresses generated by a 64-bit scalar base plus vector index. The index values are optionally first sign or zero-extended from 32 to 64 bits and then optionally multiplied by 8. Inactive elements will not cause a read from Device memory or signal faults, and are set to zero in the destination vector.
In all cases, it looks like esize is 64 and msize is 64. It's only offs_size that is 32 or 64

This is for:

 /// <summary>
/// svint32_t svld1_gather[_u32base]_s32(svbool_t pg, svuint32_t bases)
/// LD1W Zresult.S, Pg/Z, [Zbases.S, #0]
/// </summary>
public static unsafe Vector<int> GatherVector(Vector<int> mask, Vector<uint> addresses) => GatherVector(mask, addresses);

Which maps to Gather load unsigned words to vector (immediate index) with an immediate value of 0.
The addresses are 32bit (with esize = 32) and then zero extended to 64bits.

Unless we can the address of a C# object to fit into a 32bit address I can't see this working.

tannergooding · 2024-06-10T16:22:51Z

Unless we can the address of a C# object to fit into a 32bit address I can't see this working.

I don't see the issue. This doesn't have anything to do with objects, but rather truncated pointers. That is, Vector<T> addresses represents the pointers into fixed memory where that address is in the first 4GB of the address space.

While it isn't usable for an arbitrary T*, it can still be used for reading from explicitly mapped memory such as you might have in more advanced user scenarios. -- The same scenarios you'd use it for in C/C++

a74nh · 2024-06-10T19:26:50Z

Unless we can the address of a C# object to fit into a 32bit address I can't see this working.
I don't see the issue. This doesn't have anything to do with objects, but rather truncated pointers. That is, Vector<T> addresses represents the pointers into fixed memory where that address is in the first 4GB of the address space.
While it isn't usable for an arbitrary T*, it can still be used for reading from explicitly mapped memory such as you might have in more advanced user scenarios. -- The same scenarios you'd use it for in C/C++

Ok, that's fair, I wasn't sure it was possible to restrict memory in that way in C#.

Do you have any pointers on how I might construct a blob of memory the first 4GB in C# for the test case?

tannergooding · 2024-06-10T19:36:41Z

You'd need to use an API like VirtualAlloc on Windows, such as via P/Invoke: https://learn.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualalloc. An equivalent, such as mmap, would need to be used on Unix.

It should be roughly equivalent to how you'd test the same functionality in C/C++

kunalspathak · 2024-06-10T20:45:00Z

You'd need to use an API like VirtualAlloc on Windows, such as via P/Invoke: https://learn.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualalloc. An equivalent, such as mmap, would need to be used on Unix.
It should be roughly equivalent to how you'd test the same functionality in C/C++

I don't want to spend too much time on writing test for this scenario, given that we have around 40% APIs to complete in .NET 9. For now, I will just comment out exposing these APIs and come back to it once we have some cycles.

a74nh · 2024-06-11T10:19:29Z

I don't want to spend too much time on writing test for this scenario, given that we have around 40% APIs to complete in .NET 9. For now, I will just comment out exposing these APIs and come back to it once we have some cycles.

Agreed - gather vector is likely to be infrequently used. Use of variants with a 32bit address will be much rarer.

I've removed them from the external API files, but left them commented out in internal files. That should make it easier to revive later.

a74nh · 2024-06-11T10:52:38Z

Stress results.
Looks like all the failures are known predicate issues during Stress 2 + Stress Regs 1.

kunalspathak

LGTM, after we put back the 32-bit address APIs with a comment pointing to #103297

kunalspathak

LGTM. Thanks!

kunalspathak · 2024-06-12T16:37:38Z

/ba-g failures are because of #103354

a74nh · 2024-06-07T11:08:39Z

No description provided.

ghost · 2024-06-07T11:08:45Z

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, 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.

ghost · 2024-06-07T11:08:46Z

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, 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.

dotnet-policy-service · 2024-06-07T11:09:17Z

Tagging subscribers to this area: @dotnet/area-system-runtime-intrinsics
See info in area-owners.md if you want to be subscribed.

a74nh · 2024-06-07T11:14:24Z

This is working.

However, 3 tests are commented out. These are the ones with Vector<uint> for the address. Eg:

publicstaticunsafeVector<float>GatherVector(Vector<float>mask,Vector<uint>addresses);

I don't think this works for C#.

Each address is a 32bit value. Sve is only for Arm64.

@tannergooding : thoughts?

a74nh · 2024-06-07T11:53:26Z

@dotnet/arm64-contrib @kunalspathak

a74nh · 2024-06-07T13:01:37Z

Stress tests results

Looks like two errors:

Incorrect values loaded, probably due to incorrect predicates (the known issue?)
~~2) Segfault due to invalid memory load, always in GatherVector_Indices_float_int. Investigating this.~~

a74nh · 2024-06-07T13:19:40Z

Stress tests results
Looks like two errors:
Incorrect values loaded, probably due to incorrect predicates (the known issue?)
Segfault due to invalid memory load, always in GatherVector_Indices_float_int. Investigating this.

Scratch error 2 - those were due to running on a 256bit machine (and therefore issues around storing to the stack).
So just error 1, which looks like the known predicate issue.

kunalspathak

looks good overall. added some comments.

kunalspathak · 2024-06-07T13:44:10Z

+
+ if (auxSize == EA_8BYTE)
+ {
+ opt = varTypeIsUnsigned(auxType) ? INS_OPTS_SCALABLE_D_UXTW : INS_OPTS_SCALABLE_D_SXTW;


From the summary docs, we are emitting LD1D Zresult.D, Pg/Z, [Xbase, Zindices.D, LSL #3], which does not take xs field, so we do not have to embed UXTW or SXTW bit, right?

From the summary docs, we are emitting LD1D Zresult.D, Pg/Z, [Xbase, Zindices.D, LSL #3],
Correct
which does not take xs field, so we do not have to embed UXTW or SXTW bit, right?
Removing this, I get an asset (in emitarm64sve.cpp:6441). Looks like emit is expecting this field. I'll have to debug it a little more. There are a lot of different loads and I don't want to break any of them.

so you are saying that although we pass the *XTW flag, we are not using it in for this instruction, although the code path flows through the emitarm64sve.cpp that you mentioned?

Looks like it's using the flag to make a decision to decide on the correct encoding. Then doesn't use it later. Probably just needs a fix in emit.

Probably just needs a fix in emit.
Did you fix it in this PR?

Addressing modes now fixed. There are three variants for "address with vector of offsets":
Vector<64bit> GatherVector(Vector<64bit> mask, 64bit* address, Vector<64bit> indices) -> LD1D Zresult.D, Pg/Z, [Xbase, Zindices.D, LSL #3]
Vector<32bit> GatherVector(Vector<32bit> mask, 32bit* address, Vector<signed32bit> indices) -> LD1W Zresult.S, Pg/Z, [Xbase, Zindices.S, SXTW #2]
Vector<32bit> GatherVector(Vector<32bit> mask, 32bit* address, Vector<unsigned32bit> indices) -> LD1W Zresult.S, Pg/Z, [Xbase, Zindices.S, UXTW #2]
Codegen now picks the correct ones

tannergooding · 2024-06-07T17:28:07Z

@tannergooding : thoughts?

If there is an encoding that allows this parameter to be Vector<uint> then we should expose the corresponding managed API.

Having trouble following the SVE docs here since there are like 8+ different instructions called LD1D, some of which are for contiguous and some of which are for gather....

But it looks like LD1D (scalar plus vector) only allows the indexes to be 32-bit

Gather load of doublewords to active elements of a vector register from memory addresses generated by a 64-bit scalar base plus vector index. The index values are optionally first sign or zero-extended from 32 to 64 bits and then optionally multiplied by 8. Inactive elements will not cause a read from Device memory or signal faults, and are set to zero in the destination vector.

In all cases, it looks like esize is 64 and msize is 64. It's only offs_size that is 32 or 64

a74nh · 2024-06-10T15:38:26Z

@tannergooding : thoughts?
If there is an encoding that allows this parameter to be Vector<uint> then we should expose the corresponding managed API.
Having trouble following the SVE docs here since there are like 8+ different instructions called LD1D, some of which are for contiguous and some of which are for gather....
But it looks like LD1D (scalar plus vector) only allows the indexes to be 32-bit
Gather load of doublewords to active elements of a vector register from memory addresses generated by a 64-bit scalar base plus vector index. The index values are optionally first sign or zero-extended from 32 to 64 bits and then optionally multiplied by 8. Inactive elements will not cause a read from Device memory or signal faults, and are set to zero in the destination vector.
In all cases, it looks like esize is 64 and msize is 64. It's only offs_size that is 32 or 64

This is for:

 /// <summary>
/// svint32_t svld1_gather[_u32base]_s32(svbool_t pg, svuint32_t bases)
/// LD1W Zresult.S, Pg/Z, [Zbases.S, #0]
/// </summary>
public static unsafe Vector<int> GatherVector(Vector<int> mask, Vector<uint> addresses) => GatherVector(mask, addresses);

Which maps to Gather load unsigned words to vector (immediate index) with an immediate value of 0.
The addresses are 32bit (with esize = 32) and then zero extended to 64bits.

Unless we can the address of a C# object to fit into a 32bit address I can't see this working.

tannergooding · 2024-06-10T16:22:51Z

Unless we can the address of a C# object to fit into a 32bit address I can't see this working.

I don't see the issue. This doesn't have anything to do with objects, but rather truncated pointers. That is, Vector<T> addresses represents the pointers into fixed memory where that address is in the first 4GB of the address space.

While it isn't usable for an arbitrary T*, it can still be used for reading from explicitly mapped memory such as you might have in more advanced user scenarios. -- The same scenarios you'd use it for in C/C++

a74nh · 2024-06-10T19:26:50Z

Unless we can the address of a C# object to fit into a 32bit address I can't see this working.
I don't see the issue. This doesn't have anything to do with objects, but rather truncated pointers. That is, Vector<T> addresses represents the pointers into fixed memory where that address is in the first 4GB of the address space.
While it isn't usable for an arbitrary T*, it can still be used for reading from explicitly mapped memory such as you might have in more advanced user scenarios. -- The same scenarios you'd use it for in C/C++

Ok, that's fair, I wasn't sure it was possible to restrict memory in that way in C#.

Do you have any pointers on how I might construct a blob of memory the first 4GB in C# for the test case?

tannergooding · 2024-06-10T19:36:41Z

You'd need to use an API like VirtualAlloc on Windows, such as via P/Invoke: https://learn.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualalloc. An equivalent, such as mmap, would need to be used on Unix.

It should be roughly equivalent to how you'd test the same functionality in C/C++

kunalspathak · 2024-06-10T20:45:00Z

You'd need to use an API like VirtualAlloc on Windows, such as via P/Invoke: https://learn.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualalloc. An equivalent, such as mmap, would need to be used on Unix.
It should be roughly equivalent to how you'd test the same functionality in C/C++

I don't want to spend too much time on writing test for this scenario, given that we have around 40% APIs to complete in .NET 9. For now, I will just comment out exposing these APIs and come back to it once we have some cycles.

a74nh · 2024-06-11T10:19:29Z

I don't want to spend too much time on writing test for this scenario, given that we have around 40% APIs to complete in .NET 9. For now, I will just comment out exposing these APIs and come back to it once we have some cycles.

Agreed - gather vector is likely to be infrequently used. Use of variants with a 32bit address will be much rarer.

I've removed them from the external API files, but left them commented out in internal files. That should make it easier to revive later.

a74nh · 2024-06-11T10:52:38Z

Stress results.
Looks like all the failures are known predicate issues during Stress 2 + Stress Regs 1.

kunalspathak

LGTM, after we put back the 32-bit address APIs with a comment pointing to #103297

kunalspathak

LGTM. Thanks!

kunalspathak · 2024-06-12T16:37:38Z

/ba-g failures are because of #103354

a74nh · 2024-06-07T11:08:39Z

No description provided.

ghost · 2024-06-07T11:08:45Z

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, 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.

ghost · 2024-06-07T11:08:46Z

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, 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.

dotnet-policy-service · 2024-06-07T11:09:17Z

Tagging subscribers to this area: @dotnet/area-system-runtime-intrinsics
See info in area-owners.md if you want to be subscribed.

a74nh · 2024-06-07T11:14:24Z

This is working.

However, 3 tests are commented out. These are the ones with Vector<uint> for the address. Eg:

publicstaticunsafeVector<float>GatherVector(Vector<float>mask,Vector<uint>addresses);

I don't think this works for C#.

Each address is a 32bit value. Sve is only for Arm64.

@tannergooding : thoughts?

a74nh · 2024-06-07T11:53:26Z

@dotnet/arm64-contrib @kunalspathak

a74nh · 2024-06-07T13:01:37Z

Stress tests results

Looks like two errors:

Incorrect values loaded, probably due to incorrect predicates (the known issue?)
~~2) Segfault due to invalid memory load, always in GatherVector_Indices_float_int. Investigating this.~~

a74nh · 2024-06-07T13:19:40Z

Stress tests results
Looks like two errors:
Incorrect values loaded, probably due to incorrect predicates (the known issue?)
Segfault due to invalid memory load, always in GatherVector_Indices_float_int. Investigating this.

Scratch error 2 - those were due to running on a 256bit machine (and therefore issues around storing to the stack).
So just error 1, which looks like the known predicate issue.

kunalspathak

looks good overall. added some comments.

kunalspathak · 2024-06-07T13:44:10Z

+
+ if (auxSize == EA_8BYTE)
+ {
+ opt = varTypeIsUnsigned(auxType) ? INS_OPTS_SCALABLE_D_UXTW : INS_OPTS_SCALABLE_D_SXTW;


From the summary docs, we are emitting LD1D Zresult.D, Pg/Z, [Xbase, Zindices.D, LSL #3], which does not take xs field, so we do not have to embed UXTW or SXTW bit, right?

From the summary docs, we are emitting LD1D Zresult.D, Pg/Z, [Xbase, Zindices.D, LSL #3],
Correct
which does not take xs field, so we do not have to embed UXTW or SXTW bit, right?
Removing this, I get an asset (in emitarm64sve.cpp:6441). Looks like emit is expecting this field. I'll have to debug it a little more. There are a lot of different loads and I don't want to break any of them.

so you are saying that although we pass the *XTW flag, we are not using it in for this instruction, although the code path flows through the emitarm64sve.cpp that you mentioned?

Looks like it's using the flag to make a decision to decide on the correct encoding. Then doesn't use it later. Probably just needs a fix in emit.

Probably just needs a fix in emit.
Did you fix it in this PR?

Addressing modes now fixed. There are three variants for "address with vector of offsets":
Vector<64bit> GatherVector(Vector<64bit> mask, 64bit* address, Vector<64bit> indices) -> LD1D Zresult.D, Pg/Z, [Xbase, Zindices.D, LSL #3]
Vector<32bit> GatherVector(Vector<32bit> mask, 32bit* address, Vector<signed32bit> indices) -> LD1W Zresult.S, Pg/Z, [Xbase, Zindices.S, SXTW #2]
Vector<32bit> GatherVector(Vector<32bit> mask, 32bit* address, Vector<unsigned32bit> indices) -> LD1W Zresult.S, Pg/Z, [Xbase, Zindices.S, UXTW #2]
Codegen now picks the correct ones

tannergooding · 2024-06-07T17:28:07Z

@tannergooding : thoughts?

If there is an encoding that allows this parameter to be Vector<uint> then we should expose the corresponding managed API.

Having trouble following the SVE docs here since there are like 8+ different instructions called LD1D, some of which are for contiguous and some of which are for gather....

But it looks like LD1D (scalar plus vector) only allows the indexes to be 32-bit

Gather load of doublewords to active elements of a vector register from memory addresses generated by a 64-bit scalar base plus vector index. The index values are optionally first sign or zero-extended from 32 to 64 bits and then optionally multiplied by 8. Inactive elements will not cause a read from Device memory or signal faults, and are set to zero in the destination vector.

In all cases, it looks like esize is 64 and msize is 64. It's only offs_size that is 32 or 64

a74nh · 2024-06-10T15:38:26Z

@tannergooding : thoughts?
If there is an encoding that allows this parameter to be Vector<uint> then we should expose the corresponding managed API.
Having trouble following the SVE docs here since there are like 8+ different instructions called LD1D, some of which are for contiguous and some of which are for gather....
But it looks like LD1D (scalar plus vector) only allows the indexes to be 32-bit
Gather load of doublewords to active elements of a vector register from memory addresses generated by a 64-bit scalar base plus vector index. The index values are optionally first sign or zero-extended from 32 to 64 bits and then optionally multiplied by 8. Inactive elements will not cause a read from Device memory or signal faults, and are set to zero in the destination vector.
In all cases, it looks like esize is 64 and msize is 64. It's only offs_size that is 32 or 64

This is for:

 /// <summary>
/// svint32_t svld1_gather[_u32base]_s32(svbool_t pg, svuint32_t bases)
/// LD1W Zresult.S, Pg/Z, [Zbases.S, #0]
/// </summary>
public static unsafe Vector<int> GatherVector(Vector<int> mask, Vector<uint> addresses) => GatherVector(mask, addresses);

Which maps to Gather load unsigned words to vector (immediate index) with an immediate value of 0.
The addresses are 32bit (with esize = 32) and then zero extended to 64bits.

Unless we can the address of a C# object to fit into a 32bit address I can't see this working.

tannergooding · 2024-06-10T16:22:51Z

Unless we can the address of a C# object to fit into a 32bit address I can't see this working.

I don't see the issue. This doesn't have anything to do with objects, but rather truncated pointers. That is, Vector<T> addresses represents the pointers into fixed memory where that address is in the first 4GB of the address space.

While it isn't usable for an arbitrary T*, it can still be used for reading from explicitly mapped memory such as you might have in more advanced user scenarios. -- The same scenarios you'd use it for in C/C++

a74nh · 2024-06-10T19:26:50Z

Unless we can the address of a C# object to fit into a 32bit address I can't see this working.
I don't see the issue. This doesn't have anything to do with objects, but rather truncated pointers. That is, Vector<T> addresses represents the pointers into fixed memory where that address is in the first 4GB of the address space.
While it isn't usable for an arbitrary T*, it can still be used for reading from explicitly mapped memory such as you might have in more advanced user scenarios. -- The same scenarios you'd use it for in C/C++

Ok, that's fair, I wasn't sure it was possible to restrict memory in that way in C#.

Do you have any pointers on how I might construct a blob of memory the first 4GB in C# for the test case?

tannergooding · 2024-06-10T19:36:41Z

You'd need to use an API like VirtualAlloc on Windows, such as via P/Invoke: https://learn.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualalloc. An equivalent, such as mmap, would need to be used on Unix.

It should be roughly equivalent to how you'd test the same functionality in C/C++

kunalspathak · 2024-06-10T20:45:00Z

You'd need to use an API like VirtualAlloc on Windows, such as via P/Invoke: https://learn.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualalloc. An equivalent, such as mmap, would need to be used on Unix.
It should be roughly equivalent to how you'd test the same functionality in C/C++

I don't want to spend too much time on writing test for this scenario, given that we have around 40% APIs to complete in .NET 9. For now, I will just comment out exposing these APIs and come back to it once we have some cycles.

a74nh · 2024-06-11T10:19:29Z

I don't want to spend too much time on writing test for this scenario, given that we have around 40% APIs to complete in .NET 9. For now, I will just comment out exposing these APIs and come back to it once we have some cycles.

Agreed - gather vector is likely to be infrequently used. Use of variants with a 32bit address will be much rarer.

I've removed them from the external API files, but left them commented out in internal files. That should make it easier to revive later.

a74nh · 2024-06-11T10:52:38Z

Stress results.
Looks like all the failures are known predicate issues during Stress 2 + Stress Regs 1.

kunalspathak

LGTM, after we put back the 32-bit address APIs with a comment pointing to #103297

kunalspathak

LGTM. Thanks!

kunalspathak · 2024-06-12T16:37:38Z

/ba-g failures are because of #103354

a74nh · 2024-06-07T11:08:39Z

No description provided.

ghost · 2024-06-07T11:08:45Z

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, 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.

ghost · 2024-06-07T11:08:46Z

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, 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.

dotnet-policy-service · 2024-06-07T11:09:17Z

Tagging subscribers to this area: @dotnet/area-system-runtime-intrinsics
See info in area-owners.md if you want to be subscribed.

a74nh · 2024-06-07T11:14:24Z

This is working.

However, 3 tests are commented out. These are the ones with Vector<uint> for the address. Eg:

publicstaticunsafeVector<float>GatherVector(Vector<float>mask,Vector<uint>addresses);

I don't think this works for C#.

Each address is a 32bit value. Sve is only for Arm64.

@tannergooding : thoughts?

a74nh · 2024-06-07T11:53:26Z

@dotnet/arm64-contrib @kunalspathak

a74nh · 2024-06-07T13:01:37Z

Stress tests results

Looks like two errors:

Incorrect values loaded, probably due to incorrect predicates (the known issue?)
~~2) Segfault due to invalid memory load, always in GatherVector_Indices_float_int. Investigating this.~~

a74nh · 2024-06-07T13:19:40Z

Stress tests results
Looks like two errors:
Incorrect values loaded, probably due to incorrect predicates (the known issue?)
Segfault due to invalid memory load, always in GatherVector_Indices_float_int. Investigating this.

Scratch error 2 - those were due to running on a 256bit machine (and therefore issues around storing to the stack).
So just error 1, which looks like the known predicate issue.

kunalspathak

looks good overall. added some comments.

kunalspathak · 2024-06-07T13:44:10Z

+
+ if (auxSize == EA_8BYTE)
+ {
+ opt = varTypeIsUnsigned(auxType) ? INS_OPTS_SCALABLE_D_UXTW : INS_OPTS_SCALABLE_D_SXTW;


From the summary docs, we are emitting LD1D Zresult.D, Pg/Z, [Xbase, Zindices.D, LSL #3], which does not take xs field, so we do not have to embed UXTW or SXTW bit, right?

From the summary docs, we are emitting LD1D Zresult.D, Pg/Z, [Xbase, Zindices.D, LSL #3],
Correct
which does not take xs field, so we do not have to embed UXTW or SXTW bit, right?
Removing this, I get an asset (in emitarm64sve.cpp:6441). Looks like emit is expecting this field. I'll have to debug it a little more. There are a lot of different loads and I don't want to break any of them.

so you are saying that although we pass the *XTW flag, we are not using it in for this instruction, although the code path flows through the emitarm64sve.cpp that you mentioned?

Looks like it's using the flag to make a decision to decide on the correct encoding. Then doesn't use it later. Probably just needs a fix in emit.

Probably just needs a fix in emit.
Did you fix it in this PR?

Addressing modes now fixed. There are three variants for "address with vector of offsets":
Vector<64bit> GatherVector(Vector<64bit> mask, 64bit* address, Vector<64bit> indices) -> LD1D Zresult.D, Pg/Z, [Xbase, Zindices.D, LSL #3]
Vector<32bit> GatherVector(Vector<32bit> mask, 32bit* address, Vector<signed32bit> indices) -> LD1W Zresult.S, Pg/Z, [Xbase, Zindices.S, SXTW #2]
Vector<32bit> GatherVector(Vector<32bit> mask, 32bit* address, Vector<unsigned32bit> indices) -> LD1W Zresult.S, Pg/Z, [Xbase, Zindices.S, UXTW #2]
Codegen now picks the correct ones

tannergooding · 2024-06-07T17:28:07Z

@tannergooding : thoughts?

If there is an encoding that allows this parameter to be Vector<uint> then we should expose the corresponding managed API.

Having trouble following the SVE docs here since there are like 8+ different instructions called LD1D, some of which are for contiguous and some of which are for gather....

But it looks like LD1D (scalar plus vector) only allows the indexes to be 32-bit

Gather load of doublewords to active elements of a vector register from memory addresses generated by a 64-bit scalar base plus vector index. The index values are optionally first sign or zero-extended from 32 to 64 bits and then optionally multiplied by 8. Inactive elements will not cause a read from Device memory or signal faults, and are set to zero in the destination vector.

In all cases, it looks like esize is 64 and msize is 64. It's only offs_size that is 32 or 64

a74nh · 2024-06-10T15:38:26Z

@tannergooding : thoughts?
If there is an encoding that allows this parameter to be Vector<uint> then we should expose the corresponding managed API.
Having trouble following the SVE docs here since there are like 8+ different instructions called LD1D, some of which are for contiguous and some of which are for gather....
But it looks like LD1D (scalar plus vector) only allows the indexes to be 32-bit
Gather load of doublewords to active elements of a vector register from memory addresses generated by a 64-bit scalar base plus vector index. The index values are optionally first sign or zero-extended from 32 to 64 bits and then optionally multiplied by 8. Inactive elements will not cause a read from Device memory or signal faults, and are set to zero in the destination vector.
In all cases, it looks like esize is 64 and msize is 64. It's only offs_size that is 32 or 64

This is for:

 /// <summary>
/// svint32_t svld1_gather[_u32base]_s32(svbool_t pg, svuint32_t bases)
/// LD1W Zresult.S, Pg/Z, [Zbases.S, #0]
/// </summary>
public static unsafe Vector<int> GatherVector(Vector<int> mask, Vector<uint> addresses) => GatherVector(mask, addresses);

Which maps to Gather load unsigned words to vector (immediate index) with an immediate value of 0.
The addresses are 32bit (with esize = 32) and then zero extended to 64bits.

Unless we can the address of a C# object to fit into a 32bit address I can't see this working.

tannergooding · 2024-06-10T16:22:51Z

Unless we can the address of a C# object to fit into a 32bit address I can't see this working.

I don't see the issue. This doesn't have anything to do with objects, but rather truncated pointers. That is, Vector<T> addresses represents the pointers into fixed memory where that address is in the first 4GB of the address space.

While it isn't usable for an arbitrary T*, it can still be used for reading from explicitly mapped memory such as you might have in more advanced user scenarios. -- The same scenarios you'd use it for in C/C++

a74nh · 2024-06-10T19:26:50Z

Unless we can the address of a C# object to fit into a 32bit address I can't see this working.
I don't see the issue. This doesn't have anything to do with objects, but rather truncated pointers. That is, Vector<T> addresses represents the pointers into fixed memory where that address is in the first 4GB of the address space.
While it isn't usable for an arbitrary T*, it can still be used for reading from explicitly mapped memory such as you might have in more advanced user scenarios. -- The same scenarios you'd use it for in C/C++

Ok, that's fair, I wasn't sure it was possible to restrict memory in that way in C#.

Do you have any pointers on how I might construct a blob of memory the first 4GB in C# for the test case?

tannergooding · 2024-06-10T19:36:41Z

You'd need to use an API like VirtualAlloc on Windows, such as via P/Invoke: https://learn.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualalloc. An equivalent, such as mmap, would need to be used on Unix.

It should be roughly equivalent to how you'd test the same functionality in C/C++

kunalspathak · 2024-06-10T20:45:00Z

You'd need to use an API like VirtualAlloc on Windows, such as via P/Invoke: https://learn.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualalloc. An equivalent, such as mmap, would need to be used on Unix.
It should be roughly equivalent to how you'd test the same functionality in C/C++

I don't want to spend too much time on writing test for this scenario, given that we have around 40% APIs to complete in .NET 9. For now, I will just comment out exposing these APIs and come back to it once we have some cycles.

a74nh · 2024-06-11T10:19:29Z

I don't want to spend too much time on writing test for this scenario, given that we have around 40% APIs to complete in .NET 9. For now, I will just comment out exposing these APIs and come back to it once we have some cycles.

Agreed - gather vector is likely to be infrequently used. Use of variants with a 32bit address will be much rarer.

I've removed them from the external API files, but left them commented out in internal files. That should make it easier to revive later.

a74nh · 2024-06-11T10:52:38Z

Stress results.
Looks like all the failures are known predicate issues during Stress 2 + Stress Regs 1.

kunalspathak

LGTM, after we put back the 32-bit address APIs with a comment pointing to #103297

kunalspathak

LGTM. Thanks!

kunalspathak · 2024-06-12T16:37:38Z

/ba-g failures are because of #103354

a74nh · 2024-06-07T11:08:39Z

No description provided.

ghost · 2024-06-07T11:08:45Z

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, 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.

ghost · 2024-06-07T11:08:46Z

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, 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.

dotnet-policy-service · 2024-06-07T11:09:17Z

Tagging subscribers to this area: @dotnet/area-system-runtime-intrinsics
See info in area-owners.md if you want to be subscribed.

a74nh · 2024-06-07T11:14:24Z

This is working.

However, 3 tests are commented out. These are the ones with Vector<uint> for the address. Eg:

publicstaticunsafeVector<float>GatherVector(Vector<float>mask,Vector<uint>addresses);

I don't think this works for C#.

Each address is a 32bit value. Sve is only for Arm64.

@tannergooding : thoughts?

a74nh · 2024-06-07T11:53:26Z

@dotnet/arm64-contrib @kunalspathak

a74nh · 2024-06-07T13:01:37Z

Stress tests results

Looks like two errors:

Incorrect values loaded, probably due to incorrect predicates (the known issue?)
~~2) Segfault due to invalid memory load, always in GatherVector_Indices_float_int. Investigating this.~~

a74nh · 2024-06-07T13:19:40Z

Stress tests results
Looks like two errors:
Incorrect values loaded, probably due to incorrect predicates (the known issue?)
Segfault due to invalid memory load, always in GatherVector_Indices_float_int. Investigating this.

Scratch error 2 - those were due to running on a 256bit machine (and therefore issues around storing to the stack).
So just error 1, which looks like the known predicate issue.

kunalspathak

looks good overall. added some comments.

kunalspathak · 2024-06-07T13:44:10Z

+
+ if (auxSize == EA_8BYTE)
+ {
+ opt = varTypeIsUnsigned(auxType) ? INS_OPTS_SCALABLE_D_UXTW : INS_OPTS_SCALABLE_D_SXTW;


From the summary docs, we are emitting LD1D Zresult.D, Pg/Z, [Xbase, Zindices.D, LSL #3], which does not take xs field, so we do not have to embed UXTW or SXTW bit, right?

From the summary docs, we are emitting LD1D Zresult.D, Pg/Z, [Xbase, Zindices.D, LSL #3],
Correct
which does not take xs field, so we do not have to embed UXTW or SXTW bit, right?
Removing this, I get an asset (in emitarm64sve.cpp:6441). Looks like emit is expecting this field. I'll have to debug it a little more. There are a lot of different loads and I don't want to break any of them.

so you are saying that although we pass the *XTW flag, we are not using it in for this instruction, although the code path flows through the emitarm64sve.cpp that you mentioned?

Looks like it's using the flag to make a decision to decide on the correct encoding. Then doesn't use it later. Probably just needs a fix in emit.

Probably just needs a fix in emit.
Did you fix it in this PR?

Addressing modes now fixed. There are three variants for "address with vector of offsets":
Vector<64bit> GatherVector(Vector<64bit> mask, 64bit* address, Vector<64bit> indices) -> LD1D Zresult.D, Pg/Z, [Xbase, Zindices.D, LSL #3]
Vector<32bit> GatherVector(Vector<32bit> mask, 32bit* address, Vector<signed32bit> indices) -> LD1W Zresult.S, Pg/Z, [Xbase, Zindices.S, SXTW #2]
Vector<32bit> GatherVector(Vector<32bit> mask, 32bit* address, Vector<unsigned32bit> indices) -> LD1W Zresult.S, Pg/Z, [Xbase, Zindices.S, UXTW #2]
Codegen now picks the correct ones

tannergooding · 2024-06-07T17:28:07Z

@tannergooding : thoughts?

If there is an encoding that allows this parameter to be Vector<uint> then we should expose the corresponding managed API.

Having trouble following the SVE docs here since there are like 8+ different instructions called LD1D, some of which are for contiguous and some of which are for gather....

But it looks like LD1D (scalar plus vector) only allows the indexes to be 32-bit

Gather load of doublewords to active elements of a vector register from memory addresses generated by a 64-bit scalar base plus vector index. The index values are optionally first sign or zero-extended from 32 to 64 bits and then optionally multiplied by 8. Inactive elements will not cause a read from Device memory or signal faults, and are set to zero in the destination vector.

In all cases, it looks like esize is 64 and msize is 64. It's only offs_size that is 32 or 64

a74nh · 2024-06-10T15:38:26Z

@tannergooding : thoughts?
If there is an encoding that allows this parameter to be Vector<uint> then we should expose the corresponding managed API.
Having trouble following the SVE docs here since there are like 8+ different instructions called LD1D, some of which are for contiguous and some of which are for gather....
But it looks like LD1D (scalar plus vector) only allows the indexes to be 32-bit
Gather load of doublewords to active elements of a vector register from memory addresses generated by a 64-bit scalar base plus vector index. The index values are optionally first sign or zero-extended from 32 to 64 bits and then optionally multiplied by 8. Inactive elements will not cause a read from Device memory or signal faults, and are set to zero in the destination vector.
In all cases, it looks like esize is 64 and msize is 64. It's only offs_size that is 32 or 64

This is for:

 /// <summary>
/// svint32_t svld1_gather[_u32base]_s32(svbool_t pg, svuint32_t bases)
/// LD1W Zresult.S, Pg/Z, [Zbases.S, #0]
/// </summary>
public static unsafe Vector<int> GatherVector(Vector<int> mask, Vector<uint> addresses) => GatherVector(mask, addresses);

Which maps to Gather load unsigned words to vector (immediate index) with an immediate value of 0.
The addresses are 32bit (with esize = 32) and then zero extended to 64bits.

Unless we can the address of a C# object to fit into a 32bit address I can't see this working.

tannergooding · 2024-06-10T16:22:51Z

Unless we can the address of a C# object to fit into a 32bit address I can't see this working.

I don't see the issue. This doesn't have anything to do with objects, but rather truncated pointers. That is, Vector<T> addresses represents the pointers into fixed memory where that address is in the first 4GB of the address space.

While it isn't usable for an arbitrary T*, it can still be used for reading from explicitly mapped memory such as you might have in more advanced user scenarios. -- The same scenarios you'd use it for in C/C++

a74nh · 2024-06-10T19:26:50Z

Unless we can the address of a C# object to fit into a 32bit address I can't see this working.
I don't see the issue. This doesn't have anything to do with objects, but rather truncated pointers. That is, Vector<T> addresses represents the pointers into fixed memory where that address is in the first 4GB of the address space.
While it isn't usable for an arbitrary T*, it can still be used for reading from explicitly mapped memory such as you might have in more advanced user scenarios. -- The same scenarios you'd use it for in C/C++

Ok, that's fair, I wasn't sure it was possible to restrict memory in that way in C#.

Do you have any pointers on how I might construct a blob of memory the first 4GB in C# for the test case?

tannergooding · 2024-06-10T19:36:41Z

You'd need to use an API like VirtualAlloc on Windows, such as via P/Invoke: https://learn.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualalloc. An equivalent, such as mmap, would need to be used on Unix.

It should be roughly equivalent to how you'd test the same functionality in C/C++

kunalspathak · 2024-06-10T20:45:00Z

You'd need to use an API like VirtualAlloc on Windows, such as via P/Invoke: https://learn.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualalloc. An equivalent, such as mmap, would need to be used on Unix.
It should be roughly equivalent to how you'd test the same functionality in C/C++

I don't want to spend too much time on writing test for this scenario, given that we have around 40% APIs to complete in .NET 9. For now, I will just comment out exposing these APIs and come back to it once we have some cycles.

a74nh · 2024-06-11T10:19:29Z

I don't want to spend too much time on writing test for this scenario, given that we have around 40% APIs to complete in .NET 9. For now, I will just comment out exposing these APIs and come back to it once we have some cycles.

Agreed - gather vector is likely to be infrequently used. Use of variants with a 32bit address will be much rarer.

I've removed them from the external API files, but left them commented out in internal files. That should make it easier to revive later.

a74nh · 2024-06-11T10:52:38Z

Stress results.
Looks like all the failures are known predicate issues during Stress 2 + Stress Regs 1.

kunalspathak

LGTM, after we put back the 32-bit address APIs with a comment pointing to #103297

kunalspathak

LGTM. Thanks!

kunalspathak · 2024-06-12T16:37:38Z

/ba-g failures are because of #103354

ghost added area-System.Runtime.Intrinsics new-api-needs-documentation labels Jun 7, 2024

dotnet-policy-serviceBot added the community-contribution Indicates that the PR has been added by a community member label Jun 7, 2024

ARM64-SVE: gathervector
7ed74a3

a74nh force-pushed the gatherload_github branch from 8d0ac71 to 7ed74a3Compare June 7, 2024 11:11

a74nh marked this pull request as ready for review June 7, 2024 11:14

HW_Flag_LowMaskedOperation
c7d4fc4

kunalspathak added the arm-sve Work related to arm64 SVE/SVE2 support label Jun 7, 2024

kunalspathak mentioned this pull request Jun 7, 2024
Arm64: Implement SVE APIs #99957
Closed

kunalspathak suggested changes Jun 7, 2024
View reviewed changes

Remove HW_Flag_BaseTypeFromFirstArg and add asserts
42dc35c

a74nh added 2 commits June 10, 2024 16:29

Add invalid testing
f3c5eb4

Add conditional select testing
60dc92f

build-analysisBot mentioned this pull request Jun 10, 2024
Dead lettering tests #101524
Closed

a74nh added 2 commits June 11, 2024 11:00

Use LSL_N for 64bit address variants
747aa17

Remove 32bit address base variants from API
1942bde

This was referenced Jun 11, 2024
System.Data.OleDb.Tests timeout in net48 x86 Release leg #87783
Closed
[browser][ST] Wasm tests timeout #103246
Closed

kunalspathak mentioned this pull request Jun 11, 2024
Arm64/Sve: Implement the SVE APIs that takes 32-bit address as input #103297
Open

kunalspathak reviewed Jun 11, 2024
View reviewed changes

Comment thread...braries/System.Private.CoreLib/src/System/Runtime/Intrinsics/Arm/Sve.PlatformNotSupported.cs Outdated

kunalspathak approved these changes Jun 11, 2024
View reviewed changes

a74nh added 3 commits June 12, 2024 09:46

re-add commented out 32bit APIs
d41d2c2

Add comment on commented out methods
8066bbb

Replace triple quotes with doubles
5a62f7e

kunalspathak approved these changes Jun 12, 2024
View reviewed changes

kunalspathak mentioned this pull request Jun 12, 2024
System.Net.Security.Tests.SslStreamTlsResumeTests failing #103354
Closed

kunalspathak merged commit 3e8b786 into dotnet:mainJun 12, 2024

a74nh mentioned this pull request Jun 12, 2024
ARM64-SVE: gathervector extends #103370
Merged

build-analysisBot mentioned this pull request Jun 13, 2024
x64 test failure: DeserializeStoredObjects strings differ. #103367
Closed

a74nh deleted the gatherload_github branch June 13, 2024 10:40

github-actionsBot locked and limited conversation to collaborators Jul 14, 2024