Add lowering for As*() and dependent methods. by DeepakRajendrakumaran · Pull Request #83861 · dotnet/runtime

DeepakRajendrakumaran · 2023-03-23T23:05:31Z

This includes the following Vector512 API methods:
As(), AsByte(), AsDouble(), AsInt16(), AsInt32(), AsInt64(), AsNInt(), AsNUInt(), AsByte(), AsSingle(), AsUInt16(), AsUInt32(), AsUInt64(), AsVector(), AsVector512(), GetLower(), ToVector512()

Open :

GetUpper() is not lowered for Vector256 even though it's supported. Is this by choice?
I've marked this in code as a comment too : https://github.com/dotnet/runtime/blob/main/src/coreclr/jit/hwintrinsicxarch.cpp#L826-L841 : For us to get here Vector256.AsVector() or Vector256.AsVector256() has to be lowered which will happen only when target supports AVX2. Considering this, will we ever end up with a case where Vector<T> size = 128 and Vector256 gets lowered? I've not been able to manipulate .NET to hit this and this might be dead code. This extends for Vector512.AsVector() or Vector512.AsVector512() with xmm too

@dotnet/avx512-contrib

ghost · 2023-03-23T23:05:41Z

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch, @kunalspathak
See info in area-owners.md if you want to be subscribed.

Issue Details

This includes the following:
As(), AsByte(), AsDouble(), AsInt16(), AsInt32(), AsInt64(), AsNInt(), AsNUInt(), AsByte(), AsSingle(), AsUInt16(), AsUInt32(), AsUInt64(), AsVector(), AsVector512(), GetLower(), ToVector512()

Author:	DeepakRajendrakumaran
Assignees:	-
Labels:	`area-CodeGen-coreclr`, `community-contribution`
Milestone:	-

tannergooding · 2023-03-24T17:57:51Z

GetUpper() is not lowered for Vector256 even though it's supported. Is this by choice?

Not really, its on the backlog to add direct intrinsification and a general gtNewSimdGetUpperNode helper.

I've marked this in code as a comment too : https://github.com/dotnet/runtime/blob/main/src/coreclr/jit/hwintrinsicxarch.cpp#L826-L841 : For us to get here Vector256.AsVector() or Vector256.AsVector256() has to be lowered which will happen only when target supports AVX2. Considering this, will we ever end up with a case where Vector size = 128 and Vector256 gets lowered? I've not been able to manipulate .NET to hit this and this might be dead code. This extends for Vector512.AsVector() or Vector512.AsVector512() with xmm too

This is hit when Avx is supported but Avx2 is not supported. Try setting DOTNET_EnableAVX2=0. That should result in Vector256<T>.IsHardwareAccelerated == true but sizeof(Vector<T>) == 16.

We accelerate only a subset of Vector256 in this case, notably the ones flagged as HW_Flag_AvxOnlyCompatible

This includes the following: As(), AsByte(), AsDouble(), AsInt16(), AsInt32(), AsInt64(), AsNInt(), AsNUInt(), AsByte(), AsSingle(), AsUInt16(), AsUInt32(), AsUInt64(), AsVector(), AsVector512(), GetLower(), ToVector512()

tannergooding · 2023-03-27T19:24:51Z

Changes overall LGTM. Just a few code cleanup requests.

tannergooding · 2023-03-27T19:26:16Z

Not really, its on the backlog to add direct intrinsification and a general gtNewSimdGetUpperNode helper.

Draft PR for that is here: #83982. I plan on finishing it after this PR goes in and will have it cover the new Vector512 paths you added at that time.

tannergooding · 2023-03-28T13:39:42Z

Failure is unrelated and being handled by #84012

tannergooding · 2023-03-28T13:40:00Z

CC. @dotnet/jit-contrib, @dotnet/avx512-contrib for secondary review and merge

DeepakRajendrakumaran · 2023-03-23T23:05:31Z

This includes the following Vector512 API methods:
As(), AsByte(), AsDouble(), AsInt16(), AsInt32(), AsInt64(), AsNInt(), AsNUInt(), AsByte(), AsSingle(), AsUInt16(), AsUInt32(), AsUInt64(), AsVector(), AsVector512(), GetLower(), ToVector512()

Open :

GetUpper() is not lowered for Vector256 even though it's supported. Is this by choice?
I've marked this in code as a comment too : https://github.com/dotnet/runtime/blob/main/src/coreclr/jit/hwintrinsicxarch.cpp#L826-L841 : For us to get here Vector256.AsVector() or Vector256.AsVector256() has to be lowered which will happen only when target supports AVX2. Considering this, will we ever end up with a case where Vector<T> size = 128 and Vector256 gets lowered? I've not been able to manipulate .NET to hit this and this might be dead code. This extends for Vector512.AsVector() or Vector512.AsVector512() with xmm too

@dotnet/avx512-contrib

ghost · 2023-03-23T23:05:41Z

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch, @kunalspathak
See info in area-owners.md if you want to be subscribed.

Issue Details

This includes the following:
As(), AsByte(), AsDouble(), AsInt16(), AsInt32(), AsInt64(), AsNInt(), AsNUInt(), AsByte(), AsSingle(), AsUInt16(), AsUInt32(), AsUInt64(), AsVector(), AsVector512(), GetLower(), ToVector512()

Author:	DeepakRajendrakumaran
Assignees:	-
Labels:	`area-CodeGen-coreclr`, `community-contribution`
Milestone:	-

tannergooding · 2023-03-24T17:57:51Z

GetUpper() is not lowered for Vector256 even though it's supported. Is this by choice?

Not really, its on the backlog to add direct intrinsification and a general gtNewSimdGetUpperNode helper.

I've marked this in code as a comment too : https://github.com/dotnet/runtime/blob/main/src/coreclr/jit/hwintrinsicxarch.cpp#L826-L841 : For us to get here Vector256.AsVector() or Vector256.AsVector256() has to be lowered which will happen only when target supports AVX2. Considering this, will we ever end up with a case where Vector size = 128 and Vector256 gets lowered? I've not been able to manipulate .NET to hit this and this might be dead code. This extends for Vector512.AsVector() or Vector512.AsVector512() with xmm too

This is hit when Avx is supported but Avx2 is not supported. Try setting DOTNET_EnableAVX2=0. That should result in Vector256<T>.IsHardwareAccelerated == true but sizeof(Vector<T>) == 16.

We accelerate only a subset of Vector256 in this case, notably the ones flagged as HW_Flag_AvxOnlyCompatible

This includes the following: As(), AsByte(), AsDouble(), AsInt16(), AsInt32(), AsInt64(), AsNInt(), AsNUInt(), AsByte(), AsSingle(), AsUInt16(), AsUInt32(), AsUInt64(), AsVector(), AsVector512(), GetLower(), ToVector512()

tannergooding · 2023-03-27T19:24:51Z

Changes overall LGTM. Just a few code cleanup requests.

tannergooding · 2023-03-27T19:26:16Z

Not really, its on the backlog to add direct intrinsification and a general gtNewSimdGetUpperNode helper.

Draft PR for that is here: #83982. I plan on finishing it after this PR goes in and will have it cover the new Vector512 paths you added at that time.

tannergooding · 2023-03-28T13:39:42Z

Failure is unrelated and being handled by #84012

tannergooding · 2023-03-28T13:40:00Z

CC. @dotnet/jit-contrib, @dotnet/avx512-contrib for secondary review and merge

DeepakRajendrakumaran · 2023-03-23T23:05:31Z

This includes the following Vector512 API methods:
As(), AsByte(), AsDouble(), AsInt16(), AsInt32(), AsInt64(), AsNInt(), AsNUInt(), AsByte(), AsSingle(), AsUInt16(), AsUInt32(), AsUInt64(), AsVector(), AsVector512(), GetLower(), ToVector512()

Open :

GetUpper() is not lowered for Vector256 even though it's supported. Is this by choice?
I've marked this in code as a comment too : https://github.com/dotnet/runtime/blob/main/src/coreclr/jit/hwintrinsicxarch.cpp#L826-L841 : For us to get here Vector256.AsVector() or Vector256.AsVector256() has to be lowered which will happen only when target supports AVX2. Considering this, will we ever end up with a case where Vector<T> size = 128 and Vector256 gets lowered? I've not been able to manipulate .NET to hit this and this might be dead code. This extends for Vector512.AsVector() or Vector512.AsVector512() with xmm too

@dotnet/avx512-contrib

ghost · 2023-03-23T23:05:41Z

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch, @kunalspathak
See info in area-owners.md if you want to be subscribed.

Issue Details

This includes the following:
As(), AsByte(), AsDouble(), AsInt16(), AsInt32(), AsInt64(), AsNInt(), AsNUInt(), AsByte(), AsSingle(), AsUInt16(), AsUInt32(), AsUInt64(), AsVector(), AsVector512(), GetLower(), ToVector512()

Author:	DeepakRajendrakumaran
Assignees:	-
Labels:	`area-CodeGen-coreclr`, `community-contribution`
Milestone:	-

tannergooding · 2023-03-24T17:57:51Z

GetUpper() is not lowered for Vector256 even though it's supported. Is this by choice?

Not really, its on the backlog to add direct intrinsification and a general gtNewSimdGetUpperNode helper.

I've marked this in code as a comment too : https://github.com/dotnet/runtime/blob/main/src/coreclr/jit/hwintrinsicxarch.cpp#L826-L841 : For us to get here Vector256.AsVector() or Vector256.AsVector256() has to be lowered which will happen only when target supports AVX2. Considering this, will we ever end up with a case where Vector size = 128 and Vector256 gets lowered? I've not been able to manipulate .NET to hit this and this might be dead code. This extends for Vector512.AsVector() or Vector512.AsVector512() with xmm too

This is hit when Avx is supported but Avx2 is not supported. Try setting DOTNET_EnableAVX2=0. That should result in Vector256<T>.IsHardwareAccelerated == true but sizeof(Vector<T>) == 16.

We accelerate only a subset of Vector256 in this case, notably the ones flagged as HW_Flag_AvxOnlyCompatible

This includes the following: As(), AsByte(), AsDouble(), AsInt16(), AsInt32(), AsInt64(), AsNInt(), AsNUInt(), AsByte(), AsSingle(), AsUInt16(), AsUInt32(), AsUInt64(), AsVector(), AsVector512(), GetLower(), ToVector512()

tannergooding · 2023-03-27T19:24:51Z

Changes overall LGTM. Just a few code cleanup requests.

tannergooding · 2023-03-27T19:26:16Z

Not really, its on the backlog to add direct intrinsification and a general gtNewSimdGetUpperNode helper.

Draft PR for that is here: #83982. I plan on finishing it after this PR goes in and will have it cover the new Vector512 paths you added at that time.

tannergooding · 2023-03-28T13:39:42Z

Failure is unrelated and being handled by #84012

tannergooding · 2023-03-28T13:40:00Z

CC. @dotnet/jit-contrib, @dotnet/avx512-contrib for secondary review and merge

DeepakRajendrakumaran · 2023-03-23T23:05:31Z

This includes the following Vector512 API methods:
As(), AsByte(), AsDouble(), AsInt16(), AsInt32(), AsInt64(), AsNInt(), AsNUInt(), AsByte(), AsSingle(), AsUInt16(), AsUInt32(), AsUInt64(), AsVector(), AsVector512(), GetLower(), ToVector512()

Open :

GetUpper() is not lowered for Vector256 even though it's supported. Is this by choice?
I've marked this in code as a comment too : https://github.com/dotnet/runtime/blob/main/src/coreclr/jit/hwintrinsicxarch.cpp#L826-L841 : For us to get here Vector256.AsVector() or Vector256.AsVector256() has to be lowered which will happen only when target supports AVX2. Considering this, will we ever end up with a case where Vector<T> size = 128 and Vector256 gets lowered? I've not been able to manipulate .NET to hit this and this might be dead code. This extends for Vector512.AsVector() or Vector512.AsVector512() with xmm too

@dotnet/avx512-contrib

ghost · 2023-03-23T23:05:41Z

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch, @kunalspathak
See info in area-owners.md if you want to be subscribed.

Issue Details

This includes the following:
As(), AsByte(), AsDouble(), AsInt16(), AsInt32(), AsInt64(), AsNInt(), AsNUInt(), AsByte(), AsSingle(), AsUInt16(), AsUInt32(), AsUInt64(), AsVector(), AsVector512(), GetLower(), ToVector512()

Author:	DeepakRajendrakumaran
Assignees:	-
Labels:	`area-CodeGen-coreclr`, `community-contribution`
Milestone:	-

tannergooding · 2023-03-24T17:57:51Z

GetUpper() is not lowered for Vector256 even though it's supported. Is this by choice?

Not really, its on the backlog to add direct intrinsification and a general gtNewSimdGetUpperNode helper.

I've marked this in code as a comment too : https://github.com/dotnet/runtime/blob/main/src/coreclr/jit/hwintrinsicxarch.cpp#L826-L841 : For us to get here Vector256.AsVector() or Vector256.AsVector256() has to be lowered which will happen only when target supports AVX2. Considering this, will we ever end up with a case where Vector size = 128 and Vector256 gets lowered? I've not been able to manipulate .NET to hit this and this might be dead code. This extends for Vector512.AsVector() or Vector512.AsVector512() with xmm too

This is hit when Avx is supported but Avx2 is not supported. Try setting DOTNET_EnableAVX2=0. That should result in Vector256<T>.IsHardwareAccelerated == true but sizeof(Vector<T>) == 16.

We accelerate only a subset of Vector256 in this case, notably the ones flagged as HW_Flag_AvxOnlyCompatible

This includes the following: As(), AsByte(), AsDouble(), AsInt16(), AsInt32(), AsInt64(), AsNInt(), AsNUInt(), AsByte(), AsSingle(), AsUInt16(), AsUInt32(), AsUInt64(), AsVector(), AsVector512(), GetLower(), ToVector512()

tannergooding · 2023-03-27T19:24:51Z

Changes overall LGTM. Just a few code cleanup requests.

tannergooding · 2023-03-27T19:26:16Z

Not really, its on the backlog to add direct intrinsification and a general gtNewSimdGetUpperNode helper.

Draft PR for that is here: #83982. I plan on finishing it after this PR goes in and will have it cover the new Vector512 paths you added at that time.

tannergooding · 2023-03-28T13:39:42Z

Failure is unrelated and being handled by #84012

tannergooding · 2023-03-28T13:40:00Z

CC. @dotnet/jit-contrib, @dotnet/avx512-contrib for secondary review and merge

DeepakRajendrakumaran · 2023-03-23T23:05:31Z

This includes the following Vector512 API methods:
As(), AsByte(), AsDouble(), AsInt16(), AsInt32(), AsInt64(), AsNInt(), AsNUInt(), AsByte(), AsSingle(), AsUInt16(), AsUInt32(), AsUInt64(), AsVector(), AsVector512(), GetLower(), ToVector512()

Open :

GetUpper() is not lowered for Vector256 even though it's supported. Is this by choice?
I've marked this in code as a comment too : https://github.com/dotnet/runtime/blob/main/src/coreclr/jit/hwintrinsicxarch.cpp#L826-L841 : For us to get here Vector256.AsVector() or Vector256.AsVector256() has to be lowered which will happen only when target supports AVX2. Considering this, will we ever end up with a case where Vector<T> size = 128 and Vector256 gets lowered? I've not been able to manipulate .NET to hit this and this might be dead code. This extends for Vector512.AsVector() or Vector512.AsVector512() with xmm too

@dotnet/avx512-contrib

ghost · 2023-03-23T23:05:41Z

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch, @kunalspathak
See info in area-owners.md if you want to be subscribed.

Issue Details

This includes the following:
As(), AsByte(), AsDouble(), AsInt16(), AsInt32(), AsInt64(), AsNInt(), AsNUInt(), AsByte(), AsSingle(), AsUInt16(), AsUInt32(), AsUInt64(), AsVector(), AsVector512(), GetLower(), ToVector512()

Author:	DeepakRajendrakumaran
Assignees:	-
Labels:	`area-CodeGen-coreclr`, `community-contribution`
Milestone:	-

tannergooding · 2023-03-24T17:57:51Z

GetUpper() is not lowered for Vector256 even though it's supported. Is this by choice?

Not really, its on the backlog to add direct intrinsification and a general gtNewSimdGetUpperNode helper.

I've marked this in code as a comment too : https://github.com/dotnet/runtime/blob/main/src/coreclr/jit/hwintrinsicxarch.cpp#L826-L841 : For us to get here Vector256.AsVector() or Vector256.AsVector256() has to be lowered which will happen only when target supports AVX2. Considering this, will we ever end up with a case where Vector size = 128 and Vector256 gets lowered? I've not been able to manipulate .NET to hit this and this might be dead code. This extends for Vector512.AsVector() or Vector512.AsVector512() with xmm too

This is hit when Avx is supported but Avx2 is not supported. Try setting DOTNET_EnableAVX2=0. That should result in Vector256<T>.IsHardwareAccelerated == true but sizeof(Vector<T>) == 16.

We accelerate only a subset of Vector256 in this case, notably the ones flagged as HW_Flag_AvxOnlyCompatible

This includes the following: As(), AsByte(), AsDouble(), AsInt16(), AsInt32(), AsInt64(), AsNInt(), AsNUInt(), AsByte(), AsSingle(), AsUInt16(), AsUInt32(), AsUInt64(), AsVector(), AsVector512(), GetLower(), ToVector512()

tannergooding · 2023-03-27T19:24:51Z

Changes overall LGTM. Just a few code cleanup requests.

tannergooding · 2023-03-27T19:26:16Z

Not really, its on the backlog to add direct intrinsification and a general gtNewSimdGetUpperNode helper.

Draft PR for that is here: #83982. I plan on finishing it after this PR goes in and will have it cover the new Vector512 paths you added at that time.

tannergooding · 2023-03-28T13:39:42Z

Failure is unrelated and being handled by #84012

tannergooding · 2023-03-28T13:40:00Z

CC. @dotnet/jit-contrib, @dotnet/avx512-contrib for secondary review and merge

DeepakRajendrakumaran · 2023-03-23T23:05:31Z

This includes the following Vector512 API methods:
As(), AsByte(), AsDouble(), AsInt16(), AsInt32(), AsInt64(), AsNInt(), AsNUInt(), AsByte(), AsSingle(), AsUInt16(), AsUInt32(), AsUInt64(), AsVector(), AsVector512(), GetLower(), ToVector512()

Open :

GetUpper() is not lowered for Vector256 even though it's supported. Is this by choice?
I've marked this in code as a comment too : https://github.com/dotnet/runtime/blob/main/src/coreclr/jit/hwintrinsicxarch.cpp#L826-L841 : For us to get here Vector256.AsVector() or Vector256.AsVector256() has to be lowered which will happen only when target supports AVX2. Considering this, will we ever end up with a case where Vector<T> size = 128 and Vector256 gets lowered? I've not been able to manipulate .NET to hit this and this might be dead code. This extends for Vector512.AsVector() or Vector512.AsVector512() with xmm too

@dotnet/avx512-contrib

ghost · 2023-03-23T23:05:41Z

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch, @kunalspathak
See info in area-owners.md if you want to be subscribed.

Issue Details

This includes the following:
As(), AsByte(), AsDouble(), AsInt16(), AsInt32(), AsInt64(), AsNInt(), AsNUInt(), AsByte(), AsSingle(), AsUInt16(), AsUInt32(), AsUInt64(), AsVector(), AsVector512(), GetLower(), ToVector512()

Author:	DeepakRajendrakumaran
Assignees:	-
Labels:	`area-CodeGen-coreclr`, `community-contribution`
Milestone:	-

tannergooding · 2023-03-24T17:57:51Z

GetUpper() is not lowered for Vector256 even though it's supported. Is this by choice?

Not really, its on the backlog to add direct intrinsification and a general gtNewSimdGetUpperNode helper.

I've marked this in code as a comment too : https://github.com/dotnet/runtime/blob/main/src/coreclr/jit/hwintrinsicxarch.cpp#L826-L841 : For us to get here Vector256.AsVector() or Vector256.AsVector256() has to be lowered which will happen only when target supports AVX2. Considering this, will we ever end up with a case where Vector size = 128 and Vector256 gets lowered? I've not been able to manipulate .NET to hit this and this might be dead code. This extends for Vector512.AsVector() or Vector512.AsVector512() with xmm too

This is hit when Avx is supported but Avx2 is not supported. Try setting DOTNET_EnableAVX2=0. That should result in Vector256<T>.IsHardwareAccelerated == true but sizeof(Vector<T>) == 16.

We accelerate only a subset of Vector256 in this case, notably the ones flagged as HW_Flag_AvxOnlyCompatible

This includes the following: As(), AsByte(), AsDouble(), AsInt16(), AsInt32(), AsInt64(), AsNInt(), AsNUInt(), AsByte(), AsSingle(), AsUInt16(), AsUInt32(), AsUInt64(), AsVector(), AsVector512(), GetLower(), ToVector512()

tannergooding · 2023-03-27T19:24:51Z

Changes overall LGTM. Just a few code cleanup requests.

tannergooding · 2023-03-27T19:26:16Z

Not really, its on the backlog to add direct intrinsification and a general gtNewSimdGetUpperNode helper.

Draft PR for that is here: #83982. I plan on finishing it after this PR goes in and will have it cover the new Vector512 paths you added at that time.

tannergooding · 2023-03-28T13:39:42Z

Failure is unrelated and being handled by #84012

tannergooding · 2023-03-28T13:40:00Z

CC. @dotnet/jit-contrib, @dotnet/avx512-contrib for secondary review and merge

DeepakRajendrakumaran · 2023-03-23T23:05:31Z

This includes the following Vector512 API methods:
As(), AsByte(), AsDouble(), AsInt16(), AsInt32(), AsInt64(), AsNInt(), AsNUInt(), AsByte(), AsSingle(), AsUInt16(), AsUInt32(), AsUInt64(), AsVector(), AsVector512(), GetLower(), ToVector512()

Open :

GetUpper() is not lowered for Vector256 even though it's supported. Is this by choice?
I've marked this in code as a comment too : https://github.com/dotnet/runtime/blob/main/src/coreclr/jit/hwintrinsicxarch.cpp#L826-L841 : For us to get here Vector256.AsVector() or Vector256.AsVector256() has to be lowered which will happen only when target supports AVX2. Considering this, will we ever end up with a case where Vector<T> size = 128 and Vector256 gets lowered? I've not been able to manipulate .NET to hit this and this might be dead code. This extends for Vector512.AsVector() or Vector512.AsVector512() with xmm too

@dotnet/avx512-contrib

ghost · 2023-03-23T23:05:41Z

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch, @kunalspathak
See info in area-owners.md if you want to be subscribed.

Issue Details

This includes the following:
As(), AsByte(), AsDouble(), AsInt16(), AsInt32(), AsInt64(), AsNInt(), AsNUInt(), AsByte(), AsSingle(), AsUInt16(), AsUInt32(), AsUInt64(), AsVector(), AsVector512(), GetLower(), ToVector512()

Author:	DeepakRajendrakumaran
Assignees:	-
Labels:	`area-CodeGen-coreclr`, `community-contribution`
Milestone:	-

tannergooding · 2023-03-24T17:57:51Z

GetUpper() is not lowered for Vector256 even though it's supported. Is this by choice?

Not really, its on the backlog to add direct intrinsification and a general gtNewSimdGetUpperNode helper.

I've marked this in code as a comment too : https://github.com/dotnet/runtime/blob/main/src/coreclr/jit/hwintrinsicxarch.cpp#L826-L841 : For us to get here Vector256.AsVector() or Vector256.AsVector256() has to be lowered which will happen only when target supports AVX2. Considering this, will we ever end up with a case where Vector size = 128 and Vector256 gets lowered? I've not been able to manipulate .NET to hit this and this might be dead code. This extends for Vector512.AsVector() or Vector512.AsVector512() with xmm too

This is hit when Avx is supported but Avx2 is not supported. Try setting DOTNET_EnableAVX2=0. That should result in Vector256<T>.IsHardwareAccelerated == true but sizeof(Vector<T>) == 16.

We accelerate only a subset of Vector256 in this case, notably the ones flagged as HW_Flag_AvxOnlyCompatible

This includes the following: As(), AsByte(), AsDouble(), AsInt16(), AsInt32(), AsInt64(), AsNInt(), AsNUInt(), AsByte(), AsSingle(), AsUInt16(), AsUInt32(), AsUInt64(), AsVector(), AsVector512(), GetLower(), ToVector512()

tannergooding · 2023-03-27T19:24:51Z

Changes overall LGTM. Just a few code cleanup requests.

tannergooding · 2023-03-27T19:26:16Z

Not really, its on the backlog to add direct intrinsification and a general gtNewSimdGetUpperNode helper.

Draft PR for that is here: #83982. I plan on finishing it after this PR goes in and will have it cover the new Vector512 paths you added at that time.

tannergooding · 2023-03-28T13:39:42Z

Failure is unrelated and being handled by #84012

tannergooding · 2023-03-28T13:40:00Z

CC. @dotnet/jit-contrib, @dotnet/avx512-contrib for secondary review and merge

DeepakRajendrakumaran · 2023-03-23T23:05:31Z

This includes the following Vector512 API methods:
As(), AsByte(), AsDouble(), AsInt16(), AsInt32(), AsInt64(), AsNInt(), AsNUInt(), AsByte(), AsSingle(), AsUInt16(), AsUInt32(), AsUInt64(), AsVector(), AsVector512(), GetLower(), ToVector512()

Open :

GetUpper() is not lowered for Vector256 even though it's supported. Is this by choice?
I've marked this in code as a comment too : https://github.com/dotnet/runtime/blob/main/src/coreclr/jit/hwintrinsicxarch.cpp#L826-L841 : For us to get here Vector256.AsVector() or Vector256.AsVector256() has to be lowered which will happen only when target supports AVX2. Considering this, will we ever end up with a case where Vector<T> size = 128 and Vector256 gets lowered? I've not been able to manipulate .NET to hit this and this might be dead code. This extends for Vector512.AsVector() or Vector512.AsVector512() with xmm too

@dotnet/avx512-contrib

ghost · 2023-03-23T23:05:41Z

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch, @kunalspathak
See info in area-owners.md if you want to be subscribed.

Issue Details

This includes the following:
As(), AsByte(), AsDouble(), AsInt16(), AsInt32(), AsInt64(), AsNInt(), AsNUInt(), AsByte(), AsSingle(), AsUInt16(), AsUInt32(), AsUInt64(), AsVector(), AsVector512(), GetLower(), ToVector512()

Author:	DeepakRajendrakumaran
Assignees:	-
Labels:	`area-CodeGen-coreclr`, `community-contribution`
Milestone:	-

tannergooding · 2023-03-24T17:57:51Z

GetUpper() is not lowered for Vector256 even though it's supported. Is this by choice?

Not really, its on the backlog to add direct intrinsification and a general gtNewSimdGetUpperNode helper.

I've marked this in code as a comment too : https://github.com/dotnet/runtime/blob/main/src/coreclr/jit/hwintrinsicxarch.cpp#L826-L841 : For us to get here Vector256.AsVector() or Vector256.AsVector256() has to be lowered which will happen only when target supports AVX2. Considering this, will we ever end up with a case where Vector size = 128 and Vector256 gets lowered? I've not been able to manipulate .NET to hit this and this might be dead code. This extends for Vector512.AsVector() or Vector512.AsVector512() with xmm too

This is hit when Avx is supported but Avx2 is not supported. Try setting DOTNET_EnableAVX2=0. That should result in Vector256<T>.IsHardwareAccelerated == true but sizeof(Vector<T>) == 16.

We accelerate only a subset of Vector256 in this case, notably the ones flagged as HW_Flag_AvxOnlyCompatible

This includes the following: As(), AsByte(), AsDouble(), AsInt16(), AsInt32(), AsInt64(), AsNInt(), AsNUInt(), AsByte(), AsSingle(), AsUInt16(), AsUInt32(), AsUInt64(), AsVector(), AsVector512(), GetLower(), ToVector512()

tannergooding · 2023-03-27T19:24:51Z

Changes overall LGTM. Just a few code cleanup requests.

tannergooding · 2023-03-27T19:26:16Z

Not really, its on the backlog to add direct intrinsification and a general gtNewSimdGetUpperNode helper.

Draft PR for that is here: #83982. I plan on finishing it after this PR goes in and will have it cover the new Vector512 paths you added at that time.

tannergooding · 2023-03-28T13:39:42Z

Failure is unrelated and being handled by #84012

tannergooding · 2023-03-28T13:40:00Z

CC. @dotnet/jit-contrib, @dotnet/avx512-contrib for secondary review and merge

ghost added area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI community-contribution Indicates that the PR has been added by a community member labels Mar 23, 2023

DeepakRajendrakumaran commented Mar 23, 2023
View reviewed changes

Comment threadsrc/coreclr/jit/hwintrinsicxarch.cpp Outdated

DeepakRajendrakumaran marked this pull request as ready for review March 24, 2023 17:45

tannergooding reviewed Mar 24, 2023
View reviewed changes

Comment threadsrc/coreclr/jit/fgbasic.cpp Outdated

BruceForstall added the avx512 Related to the AVX-512 architecture label Mar 27, 2023

DeepakRajendrakumaran force-pushed the vector512API_3 branch from 2d74c64 to 1c0f713Compare March 27, 2023 18:25

DeepakRajendrakumaran added 2 commits March 27, 2023 11:30

Add lowering for As*() and dependent methods.
1eca7c6
This includes the following: As(), AsByte(), AsDouble(), AsInt16(), AsInt32(), AsInt64(), AsNInt(), AsNUInt(), AsByte(), AsSingle(), AsUInt16(), AsUInt32(), AsUInt64(), AsVector(), AsVector512(), GetLower(), ToVector512()

Handling xmm <-> zmm conversions.
1c0f713

tannergooding reviewed Mar 27, 2023
View reviewed changes

Comment threadsrc/coreclr/jit/hwintrinsiccodegenxarch.cpp

tannergooding reviewed Mar 27, 2023
View reviewed changes

Comment threadsrc/coreclr/jit/hwintrinsiccodegenxarch.cpp Outdated

tannergooding reviewed Mar 27, 2023
View reviewed changes

Comment threadsrc/coreclr/jit/hwintrinsiccodegenxarch.cpp Outdated

tannergooding reviewed Mar 27, 2023
View reviewed changes

Comment threadsrc/coreclr/jit/hwintrinsiclistxarch.h Outdated

tannergooding reviewed Mar 27, 2023
View reviewed changes

Comment threadsrc/coreclr/jit/hwintrinsiclistxarch.h Outdated

tannergooding reviewed Mar 27, 2023
View reviewed changes

Comment threadsrc/coreclr/jit/hwintrinsicxarch.cpp Outdated

Addressing review comments.
180fdc5

tannergooding approved these changes Mar 27, 2023
View reviewed changes

BruceForstall approved these changes Mar 28, 2023
View reviewed changes

BruceForstall merged commit e467e59 into dotnet:mainMar 28, 2023

ghost locked as resolved and limited conversation to collaborators Apr 28, 2023

DeepakRajendrakumaran deleted the vector512API_3 branch August 3, 2026 23:43