Add support for Sve.UnzipEven/Odd & Sve.ZipHighLow by SwapnilGaikwad · Pull Request #101294 · dotnet/runtime

SwapnilGaikwad · 2024-04-19T14:35:17Z

Add SVE API for unpredicated versions of UnzipEven, UnzipOdd, ZipHigh & ZipLow methods.

ghost · 2024-04-19T14:35:23Z

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-04-19T14:35:46Z

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

SwapnilGaikwad · 2024-04-19T14:40:58Z

On a V1 system with SVE vector length 256 bits, tests for this patch would fail. We are currently limited to vector length of 128 causing incorrect results on systems with higher vector lengths. We need #101295 to limit vector length to 128 bits.

SwapnilGaikwad · 2024-04-19T14:41:17Z

@a74nh @kunalspathak @dotnet/arm64-contrib @arch-arm64-sve

JulieLeeMSFT · 2024-04-19T18:26:49Z

Contributes to #99957

JulieLeeMSFT · 2024-04-19T18:30:46Z

Thanks @SwapnilGaikwad for the PR for bitmanipulate. When you merge the PR, could you check off the boxes from #99957?

kunalspathak · 2024-04-22T04:22:26Z

We need #101295 to limit vector length to 128 bits.

Is your plan to always limit the vector length to 128 bits? If yes, how can we test the functionality on 256 bits and higher?

kunalspathak

the changes looks good otherwise, except the comment about testing.

SwapnilGaikwad · 2024-04-22T15:12:47Z

Thanks @SwapnilGaikwad for the PR for bitmanipulate. When you merge the PR, could you check off the boxes from #99957?

I'll post a comment on the issue as I cannot edit the text of the issue 👍

SwapnilGaikwad · 2024-04-22T15:17:26Z

We need #101295 to limit vector length to 128 bits.
Is your plan to always limit the vector length to 128 bits? If yes, how can we test the functionality on 256 bits and higher?

This just for temporary workaround until we support higher vector lengths using Vector. Currently it's limited to 128bits. These changes are tested for higher vector lengths locally. Once we start supporting higher vector lengths with Vector, we don't need to limit the vector lengths using the mentioned patch. There won't be any changes required to this patch then.

kunalspathak

LGTM

kunalspathak · 2024-04-25T21:47:28Z

The only failure that BuildAnalysis didn't tag as "known issue" is actually #91757 and not sure why it didn't get tagged. cc: @JulieLeeMSFT

kunalspathak · 2024-04-25T21:47:54Z

/ba-g #91757

kunalspathak · 2024-04-25T21:52:57Z

+ /// svbool_t svuzp1_b8(svbool_t op1, svbool_t op2)
+ /// UZP1 Presult.B, Pop1.B, Pop2.B
+ /// </summary>
+ public static unsafe Vector<byte> UnzipEven(Vector<byte> left, Vector<byte> right) => UnzipEven(left, right);


I just realized that zip and unzip instructions operate on both vector and predicate registers. How do we know which one to invoke? Currently, we will always invoke vector variants? @a74nh ?
If we always going to support just the vector version, then please remove the comment for predicate registers.

Right now it'll just be the vector variant. If we're using masks then there will be a lot of conversions and the vector version will be used.
Raised a ticket: #101598
In the meantime, is it ok to leave the comment as is?

Thanks for opening an issue and yes, ok to keep it as of now.

* Add support for Sve.UnzipEven/Odd & Sve.ZipHighLow * Rename the test template --------- Co-authored-by: Kunal Pathak <Kunal.Pathak@microsoft.com>

SwapnilGaikwad · 2024-04-19T14:35:17Z

Add SVE API for unpredicated versions of UnzipEven, UnzipOdd, ZipHigh & ZipLow methods.

ghost · 2024-04-19T14:35:23Z

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-04-19T14:35:46Z

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

SwapnilGaikwad · 2024-04-19T14:40:58Z

On a V1 system with SVE vector length 256 bits, tests for this patch would fail. We are currently limited to vector length of 128 causing incorrect results on systems with higher vector lengths. We need #101295 to limit vector length to 128 bits.

SwapnilGaikwad · 2024-04-19T14:41:17Z

@a74nh @kunalspathak @dotnet/arm64-contrib @arch-arm64-sve

JulieLeeMSFT · 2024-04-19T18:26:49Z

Contributes to #99957

JulieLeeMSFT · 2024-04-19T18:30:46Z

Thanks @SwapnilGaikwad for the PR for bitmanipulate. When you merge the PR, could you check off the boxes from #99957?

kunalspathak · 2024-04-22T04:22:26Z

We need #101295 to limit vector length to 128 bits.

Is your plan to always limit the vector length to 128 bits? If yes, how can we test the functionality on 256 bits and higher?

kunalspathak

the changes looks good otherwise, except the comment about testing.

SwapnilGaikwad · 2024-04-22T15:12:47Z

Thanks @SwapnilGaikwad for the PR for bitmanipulate. When you merge the PR, could you check off the boxes from #99957?

I'll post a comment on the issue as I cannot edit the text of the issue 👍

SwapnilGaikwad · 2024-04-22T15:17:26Z

We need #101295 to limit vector length to 128 bits.
Is your plan to always limit the vector length to 128 bits? If yes, how can we test the functionality on 256 bits and higher?

This just for temporary workaround until we support higher vector lengths using Vector. Currently it's limited to 128bits. These changes are tested for higher vector lengths locally. Once we start supporting higher vector lengths with Vector, we don't need to limit the vector lengths using the mentioned patch. There won't be any changes required to this patch then.

kunalspathak

LGTM

kunalspathak · 2024-04-25T21:47:28Z

The only failure that BuildAnalysis didn't tag as "known issue" is actually #91757 and not sure why it didn't get tagged. cc: @JulieLeeMSFT

kunalspathak · 2024-04-25T21:47:54Z

/ba-g #91757

kunalspathak · 2024-04-25T21:52:57Z

+ /// svbool_t svuzp1_b8(svbool_t op1, svbool_t op2)
+ /// UZP1 Presult.B, Pop1.B, Pop2.B
+ /// </summary>
+ public static unsafe Vector<byte> UnzipEven(Vector<byte> left, Vector<byte> right) => UnzipEven(left, right);


I just realized that zip and unzip instructions operate on both vector and predicate registers. How do we know which one to invoke? Currently, we will always invoke vector variants? @a74nh ?
If we always going to support just the vector version, then please remove the comment for predicate registers.

Right now it'll just be the vector variant. If we're using masks then there will be a lot of conversions and the vector version will be used.
Raised a ticket: #101598
In the meantime, is it ok to leave the comment as is?

Thanks for opening an issue and yes, ok to keep it as of now.

* Add support for Sve.UnzipEven/Odd & Sve.ZipHighLow * Rename the test template --------- Co-authored-by: Kunal Pathak <Kunal.Pathak@microsoft.com>

SwapnilGaikwad · 2024-04-19T14:35:17Z

Add SVE API for unpredicated versions of UnzipEven, UnzipOdd, ZipHigh & ZipLow methods.

ghost · 2024-04-19T14:35:23Z

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-04-19T14:35:46Z

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

SwapnilGaikwad · 2024-04-19T14:40:58Z

On a V1 system with SVE vector length 256 bits, tests for this patch would fail. We are currently limited to vector length of 128 causing incorrect results on systems with higher vector lengths. We need #101295 to limit vector length to 128 bits.

SwapnilGaikwad · 2024-04-19T14:41:17Z

@a74nh @kunalspathak @dotnet/arm64-contrib @arch-arm64-sve

JulieLeeMSFT · 2024-04-19T18:26:49Z

Contributes to #99957

JulieLeeMSFT · 2024-04-19T18:30:46Z

Thanks @SwapnilGaikwad for the PR for bitmanipulate. When you merge the PR, could you check off the boxes from #99957?

kunalspathak · 2024-04-22T04:22:26Z

We need #101295 to limit vector length to 128 bits.

Is your plan to always limit the vector length to 128 bits? If yes, how can we test the functionality on 256 bits and higher?

kunalspathak

the changes looks good otherwise, except the comment about testing.

SwapnilGaikwad · 2024-04-22T15:12:47Z

Thanks @SwapnilGaikwad for the PR for bitmanipulate. When you merge the PR, could you check off the boxes from #99957?

I'll post a comment on the issue as I cannot edit the text of the issue 👍

SwapnilGaikwad · 2024-04-22T15:17:26Z

We need #101295 to limit vector length to 128 bits.
Is your plan to always limit the vector length to 128 bits? If yes, how can we test the functionality on 256 bits and higher?

This just for temporary workaround until we support higher vector lengths using Vector. Currently it's limited to 128bits. These changes are tested for higher vector lengths locally. Once we start supporting higher vector lengths with Vector, we don't need to limit the vector lengths using the mentioned patch. There won't be any changes required to this patch then.

kunalspathak

LGTM

kunalspathak · 2024-04-25T21:47:28Z

The only failure that BuildAnalysis didn't tag as "known issue" is actually #91757 and not sure why it didn't get tagged. cc: @JulieLeeMSFT

kunalspathak · 2024-04-25T21:47:54Z

/ba-g #91757

kunalspathak · 2024-04-25T21:52:57Z

+ /// svbool_t svuzp1_b8(svbool_t op1, svbool_t op2)
+ /// UZP1 Presult.B, Pop1.B, Pop2.B
+ /// </summary>
+ public static unsafe Vector<byte> UnzipEven(Vector<byte> left, Vector<byte> right) => UnzipEven(left, right);


I just realized that zip and unzip instructions operate on both vector and predicate registers. How do we know which one to invoke? Currently, we will always invoke vector variants? @a74nh ?
If we always going to support just the vector version, then please remove the comment for predicate registers.

Right now it'll just be the vector variant. If we're using masks then there will be a lot of conversions and the vector version will be used.
Raised a ticket: #101598
In the meantime, is it ok to leave the comment as is?

Thanks for opening an issue and yes, ok to keep it as of now.

* Add support for Sve.UnzipEven/Odd & Sve.ZipHighLow * Rename the test template --------- Co-authored-by: Kunal Pathak <Kunal.Pathak@microsoft.com>

SwapnilGaikwad · 2024-04-19T14:35:17Z

Add SVE API for unpredicated versions of UnzipEven, UnzipOdd, ZipHigh & ZipLow methods.

ghost · 2024-04-19T14:35:23Z

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-04-19T14:35:46Z

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

SwapnilGaikwad · 2024-04-19T14:40:58Z

On a V1 system with SVE vector length 256 bits, tests for this patch would fail. We are currently limited to vector length of 128 causing incorrect results on systems with higher vector lengths. We need #101295 to limit vector length to 128 bits.

SwapnilGaikwad · 2024-04-19T14:41:17Z

@a74nh @kunalspathak @dotnet/arm64-contrib @arch-arm64-sve

JulieLeeMSFT · 2024-04-19T18:26:49Z

Contributes to #99957

JulieLeeMSFT · 2024-04-19T18:30:46Z

Thanks @SwapnilGaikwad for the PR for bitmanipulate. When you merge the PR, could you check off the boxes from #99957?

kunalspathak · 2024-04-22T04:22:26Z

We need #101295 to limit vector length to 128 bits.

Is your plan to always limit the vector length to 128 bits? If yes, how can we test the functionality on 256 bits and higher?

kunalspathak

the changes looks good otherwise, except the comment about testing.

SwapnilGaikwad · 2024-04-22T15:12:47Z

Thanks @SwapnilGaikwad for the PR for bitmanipulate. When you merge the PR, could you check off the boxes from #99957?

I'll post a comment on the issue as I cannot edit the text of the issue 👍

SwapnilGaikwad · 2024-04-22T15:17:26Z

We need #101295 to limit vector length to 128 bits.
Is your plan to always limit the vector length to 128 bits? If yes, how can we test the functionality on 256 bits and higher?

This just for temporary workaround until we support higher vector lengths using Vector. Currently it's limited to 128bits. These changes are tested for higher vector lengths locally. Once we start supporting higher vector lengths with Vector, we don't need to limit the vector lengths using the mentioned patch. There won't be any changes required to this patch then.

kunalspathak

LGTM

kunalspathak · 2024-04-25T21:47:28Z

The only failure that BuildAnalysis didn't tag as "known issue" is actually #91757 and not sure why it didn't get tagged. cc: @JulieLeeMSFT

kunalspathak · 2024-04-25T21:47:54Z

/ba-g #91757

kunalspathak · 2024-04-25T21:52:57Z

+ /// svbool_t svuzp1_b8(svbool_t op1, svbool_t op2)
+ /// UZP1 Presult.B, Pop1.B, Pop2.B
+ /// </summary>
+ public static unsafe Vector<byte> UnzipEven(Vector<byte> left, Vector<byte> right) => UnzipEven(left, right);


I just realized that zip and unzip instructions operate on both vector and predicate registers. How do we know which one to invoke? Currently, we will always invoke vector variants? @a74nh ?
If we always going to support just the vector version, then please remove the comment for predicate registers.

Right now it'll just be the vector variant. If we're using masks then there will be a lot of conversions and the vector version will be used.
Raised a ticket: #101598
In the meantime, is it ok to leave the comment as is?

Thanks for opening an issue and yes, ok to keep it as of now.

* Add support for Sve.UnzipEven/Odd & Sve.ZipHighLow * Rename the test template --------- Co-authored-by: Kunal Pathak <Kunal.Pathak@microsoft.com>

SwapnilGaikwad · 2024-04-19T14:35:17Z

Add SVE API for unpredicated versions of UnzipEven, UnzipOdd, ZipHigh & ZipLow methods.

ghost · 2024-04-19T14:35:23Z

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-04-19T14:35:46Z

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

SwapnilGaikwad · 2024-04-19T14:40:58Z

On a V1 system with SVE vector length 256 bits, tests for this patch would fail. We are currently limited to vector length of 128 causing incorrect results on systems with higher vector lengths. We need #101295 to limit vector length to 128 bits.

SwapnilGaikwad · 2024-04-19T14:41:17Z

@a74nh @kunalspathak @dotnet/arm64-contrib @arch-arm64-sve

JulieLeeMSFT · 2024-04-19T18:26:49Z

Contributes to #99957

JulieLeeMSFT · 2024-04-19T18:30:46Z

Thanks @SwapnilGaikwad for the PR for bitmanipulate. When you merge the PR, could you check off the boxes from #99957?

kunalspathak · 2024-04-22T04:22:26Z

We need #101295 to limit vector length to 128 bits.

Is your plan to always limit the vector length to 128 bits? If yes, how can we test the functionality on 256 bits and higher?

kunalspathak

the changes looks good otherwise, except the comment about testing.

SwapnilGaikwad · 2024-04-22T15:12:47Z

Thanks @SwapnilGaikwad for the PR for bitmanipulate. When you merge the PR, could you check off the boxes from #99957?

I'll post a comment on the issue as I cannot edit the text of the issue 👍

SwapnilGaikwad · 2024-04-22T15:17:26Z

We need #101295 to limit vector length to 128 bits.
Is your plan to always limit the vector length to 128 bits? If yes, how can we test the functionality on 256 bits and higher?

This just for temporary workaround until we support higher vector lengths using Vector. Currently it's limited to 128bits. These changes are tested for higher vector lengths locally. Once we start supporting higher vector lengths with Vector, we don't need to limit the vector lengths using the mentioned patch. There won't be any changes required to this patch then.

kunalspathak

LGTM

kunalspathak · 2024-04-25T21:47:28Z

The only failure that BuildAnalysis didn't tag as "known issue" is actually #91757 and not sure why it didn't get tagged. cc: @JulieLeeMSFT

kunalspathak · 2024-04-25T21:47:54Z

/ba-g #91757

kunalspathak · 2024-04-25T21:52:57Z

+ /// svbool_t svuzp1_b8(svbool_t op1, svbool_t op2)
+ /// UZP1 Presult.B, Pop1.B, Pop2.B
+ /// </summary>
+ public static unsafe Vector<byte> UnzipEven(Vector<byte> left, Vector<byte> right) => UnzipEven(left, right);


I just realized that zip and unzip instructions operate on both vector and predicate registers. How do we know which one to invoke? Currently, we will always invoke vector variants? @a74nh ?
If we always going to support just the vector version, then please remove the comment for predicate registers.

Right now it'll just be the vector variant. If we're using masks then there will be a lot of conversions and the vector version will be used.
Raised a ticket: #101598
In the meantime, is it ok to leave the comment as is?

Thanks for opening an issue and yes, ok to keep it as of now.

* Add support for Sve.UnzipEven/Odd & Sve.ZipHighLow * Rename the test template --------- Co-authored-by: Kunal Pathak <Kunal.Pathak@microsoft.com>

SwapnilGaikwad · 2024-04-19T14:35:17Z

Add SVE API for unpredicated versions of UnzipEven, UnzipOdd, ZipHigh & ZipLow methods.

ghost · 2024-04-19T14:35:23Z

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-04-19T14:35:46Z

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

SwapnilGaikwad · 2024-04-19T14:40:58Z

On a V1 system with SVE vector length 256 bits, tests for this patch would fail. We are currently limited to vector length of 128 causing incorrect results on systems with higher vector lengths. We need #101295 to limit vector length to 128 bits.

SwapnilGaikwad · 2024-04-19T14:41:17Z

@a74nh @kunalspathak @dotnet/arm64-contrib @arch-arm64-sve

JulieLeeMSFT · 2024-04-19T18:26:49Z

Contributes to #99957

JulieLeeMSFT · 2024-04-19T18:30:46Z

Thanks @SwapnilGaikwad for the PR for bitmanipulate. When you merge the PR, could you check off the boxes from #99957?

kunalspathak · 2024-04-22T04:22:26Z

We need #101295 to limit vector length to 128 bits.

Is your plan to always limit the vector length to 128 bits? If yes, how can we test the functionality on 256 bits and higher?

kunalspathak

the changes looks good otherwise, except the comment about testing.

SwapnilGaikwad · 2024-04-22T15:12:47Z

Thanks @SwapnilGaikwad for the PR for bitmanipulate. When you merge the PR, could you check off the boxes from #99957?

I'll post a comment on the issue as I cannot edit the text of the issue 👍

SwapnilGaikwad · 2024-04-22T15:17:26Z

We need #101295 to limit vector length to 128 bits.
Is your plan to always limit the vector length to 128 bits? If yes, how can we test the functionality on 256 bits and higher?

This just for temporary workaround until we support higher vector lengths using Vector. Currently it's limited to 128bits. These changes are tested for higher vector lengths locally. Once we start supporting higher vector lengths with Vector, we don't need to limit the vector lengths using the mentioned patch. There won't be any changes required to this patch then.

kunalspathak

LGTM

kunalspathak · 2024-04-25T21:47:28Z

The only failure that BuildAnalysis didn't tag as "known issue" is actually #91757 and not sure why it didn't get tagged. cc: @JulieLeeMSFT

kunalspathak · 2024-04-25T21:47:54Z

/ba-g #91757

kunalspathak · 2024-04-25T21:52:57Z

+ /// svbool_t svuzp1_b8(svbool_t op1, svbool_t op2)
+ /// UZP1 Presult.B, Pop1.B, Pop2.B
+ /// </summary>
+ public static unsafe Vector<byte> UnzipEven(Vector<byte> left, Vector<byte> right) => UnzipEven(left, right);


I just realized that zip and unzip instructions operate on both vector and predicate registers. How do we know which one to invoke? Currently, we will always invoke vector variants? @a74nh ?
If we always going to support just the vector version, then please remove the comment for predicate registers.

Right now it'll just be the vector variant. If we're using masks then there will be a lot of conversions and the vector version will be used.
Raised a ticket: #101598
In the meantime, is it ok to leave the comment as is?

Thanks for opening an issue and yes, ok to keep it as of now.

* Add support for Sve.UnzipEven/Odd & Sve.ZipHighLow * Rename the test template --------- Co-authored-by: Kunal Pathak <Kunal.Pathak@microsoft.com>

SwapnilGaikwad · 2024-04-19T14:35:17Z

Add SVE API for unpredicated versions of UnzipEven, UnzipOdd, ZipHigh & ZipLow methods.

ghost · 2024-04-19T14:35:23Z

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-04-19T14:35:46Z

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

SwapnilGaikwad · 2024-04-19T14:40:58Z

On a V1 system with SVE vector length 256 bits, tests for this patch would fail. We are currently limited to vector length of 128 causing incorrect results on systems with higher vector lengths. We need #101295 to limit vector length to 128 bits.

SwapnilGaikwad · 2024-04-19T14:41:17Z

@a74nh @kunalspathak @dotnet/arm64-contrib @arch-arm64-sve

JulieLeeMSFT · 2024-04-19T18:26:49Z

Contributes to #99957

JulieLeeMSFT · 2024-04-19T18:30:46Z

Thanks @SwapnilGaikwad for the PR for bitmanipulate. When you merge the PR, could you check off the boxes from #99957?

kunalspathak · 2024-04-22T04:22:26Z

We need #101295 to limit vector length to 128 bits.

Is your plan to always limit the vector length to 128 bits? If yes, how can we test the functionality on 256 bits and higher?

kunalspathak

the changes looks good otherwise, except the comment about testing.

SwapnilGaikwad · 2024-04-22T15:12:47Z

Thanks @SwapnilGaikwad for the PR for bitmanipulate. When you merge the PR, could you check off the boxes from #99957?

I'll post a comment on the issue as I cannot edit the text of the issue 👍

SwapnilGaikwad · 2024-04-22T15:17:26Z

We need #101295 to limit vector length to 128 bits.
Is your plan to always limit the vector length to 128 bits? If yes, how can we test the functionality on 256 bits and higher?

This just for temporary workaround until we support higher vector lengths using Vector. Currently it's limited to 128bits. These changes are tested for higher vector lengths locally. Once we start supporting higher vector lengths with Vector, we don't need to limit the vector lengths using the mentioned patch. There won't be any changes required to this patch then.

kunalspathak

LGTM

kunalspathak · 2024-04-25T21:47:28Z

The only failure that BuildAnalysis didn't tag as "known issue" is actually #91757 and not sure why it didn't get tagged. cc: @JulieLeeMSFT

kunalspathak · 2024-04-25T21:47:54Z

/ba-g #91757

kunalspathak · 2024-04-25T21:52:57Z

+ /// svbool_t svuzp1_b8(svbool_t op1, svbool_t op2)
+ /// UZP1 Presult.B, Pop1.B, Pop2.B
+ /// </summary>
+ public static unsafe Vector<byte> UnzipEven(Vector<byte> left, Vector<byte> right) => UnzipEven(left, right);


I just realized that zip and unzip instructions operate on both vector and predicate registers. How do we know which one to invoke? Currently, we will always invoke vector variants? @a74nh ?
If we always going to support just the vector version, then please remove the comment for predicate registers.

Right now it'll just be the vector variant. If we're using masks then there will be a lot of conversions and the vector version will be used.
Raised a ticket: #101598
In the meantime, is it ok to leave the comment as is?

Thanks for opening an issue and yes, ok to keep it as of now.

* Add support for Sve.UnzipEven/Odd & Sve.ZipHighLow * Rename the test template --------- Co-authored-by: Kunal Pathak <Kunal.Pathak@microsoft.com>

SwapnilGaikwad · 2024-04-19T14:35:17Z

Add SVE API for unpredicated versions of UnzipEven, UnzipOdd, ZipHigh & ZipLow methods.

ghost · 2024-04-19T14:35:23Z

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-04-19T14:35:46Z

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

SwapnilGaikwad · 2024-04-19T14:40:58Z

On a V1 system with SVE vector length 256 bits, tests for this patch would fail. We are currently limited to vector length of 128 causing incorrect results on systems with higher vector lengths. We need #101295 to limit vector length to 128 bits.

SwapnilGaikwad · 2024-04-19T14:41:17Z

@a74nh @kunalspathak @dotnet/arm64-contrib @arch-arm64-sve

JulieLeeMSFT · 2024-04-19T18:26:49Z

Contributes to #99957

JulieLeeMSFT · 2024-04-19T18:30:46Z

Thanks @SwapnilGaikwad for the PR for bitmanipulate. When you merge the PR, could you check off the boxes from #99957?

kunalspathak · 2024-04-22T04:22:26Z

We need #101295 to limit vector length to 128 bits.

Is your plan to always limit the vector length to 128 bits? If yes, how can we test the functionality on 256 bits and higher?

kunalspathak

the changes looks good otherwise, except the comment about testing.

SwapnilGaikwad · 2024-04-22T15:12:47Z

Thanks @SwapnilGaikwad for the PR for bitmanipulate. When you merge the PR, could you check off the boxes from #99957?

I'll post a comment on the issue as I cannot edit the text of the issue 👍

SwapnilGaikwad · 2024-04-22T15:17:26Z

We need #101295 to limit vector length to 128 bits.
Is your plan to always limit the vector length to 128 bits? If yes, how can we test the functionality on 256 bits and higher?

This just for temporary workaround until we support higher vector lengths using Vector. Currently it's limited to 128bits. These changes are tested for higher vector lengths locally. Once we start supporting higher vector lengths with Vector, we don't need to limit the vector lengths using the mentioned patch. There won't be any changes required to this patch then.

kunalspathak

LGTM

kunalspathak · 2024-04-25T21:47:28Z

The only failure that BuildAnalysis didn't tag as "known issue" is actually #91757 and not sure why it didn't get tagged. cc: @JulieLeeMSFT

kunalspathak · 2024-04-25T21:47:54Z

/ba-g #91757

kunalspathak · 2024-04-25T21:52:57Z

+ /// svbool_t svuzp1_b8(svbool_t op1, svbool_t op2)
+ /// UZP1 Presult.B, Pop1.B, Pop2.B
+ /// </summary>
+ public static unsafe Vector<byte> UnzipEven(Vector<byte> left, Vector<byte> right) => UnzipEven(left, right);


I just realized that zip and unzip instructions operate on both vector and predicate registers. How do we know which one to invoke? Currently, we will always invoke vector variants? @a74nh ?
If we always going to support just the vector version, then please remove the comment for predicate registers.

Right now it'll just be the vector variant. If we're using masks then there will be a lot of conversions and the vector version will be used.
Raised a ticket: #101598
In the meantime, is it ok to leave the comment as is?

Thanks for opening an issue and yes, ok to keep it as of now.

* Add support for Sve.UnzipEven/Odd & Sve.ZipHighLow * Rename the test template --------- Co-authored-by: Kunal Pathak <Kunal.Pathak@microsoft.com>

Add support for Sve.UnzipEven/Odd & Sve.ZipHighLow
c5a3dc6

ghost added area-System.Runtime.Intrinsics new-api-needs-documentation labels Apr 19, 2024

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

SwapnilGaikwad mentioned this pull request Apr 19, 2024
Add option to change SVE vector length for current and children processes #101295
Merged

SwapnilGaikwad marked this pull request as ready for review April 19, 2024 14:41

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

kunalspathak self-requested a review April 21, 2024 18:15

kunalspathak reviewed Apr 22, 2024
View reviewed changes

Comment threadsrc/tests/JIT/HardwareIntrinsics/Arm/Shared/_BinaryOpSveTestTemplate.template

kunalspathak reviewed Apr 22, 2024
View reviewed changes

Rename the test template
cb9566b

kunalspathak mentioned this pull request Apr 24, 2024
Arm64: Implement SVE APIs #99957
Closed

kunalspathak approved these changes Apr 24, 2024
View reviewed changes

Merge main
d0fd883

kunalspathak closed this Apr 24, 2024

kunalspathak reopened this Apr 24, 2024

Merge main
5c2d4ef

Merge remote-tracking branch 'origin/main' into github-sve-zip
88acf3c

kunalspathak reviewed Apr 25, 2024
View reviewed changes

This was referenced Apr 25, 2024
System.IO.Net5Compat.Tests and System.IO.Tests suddenly exiting with error 137 #100558
Closed
[CI] Test failure from System.Net.Http.Functional.Tests.SocketsHttpHandlerTest_Cookies_Http3.GetAsync_DefaultCoookieContainer_NoCookieSent#101567
Closed

a74nh mentioned this pull request Apr 26, 2024
ARM64 SVE: Zip/Unzip should use predicate variant when all inputs are masks #101598
Closed

kunalspathak merged commit 9892d46 into dotnet:mainApr 26, 2024

SwapnilGaikwad deleted the github-sve-zip branch April 26, 2024 14:53

build-analysisBot mentioned this pull request May 2, 2024
[wasm][AOT][net8.0] emcc : error - received SIGKILL (-9) #89402
Open

github-actionsBot locked and limited conversation to collaborators May 27, 2024