Updating Vector<T> to support nint and nuint - #50832

Merged
tannergooding merged 19 commits into
dotnet:mainfrom
tannergooding:intrinsic-type
Apr 20, 2021
Merged

Updating Vector<T> to support nint and nuint#50832
tannergooding merged 19 commits into
dotnet:mainfrom
tannergooding:intrinsic-type

Conversation

@tannergooding

@tannergoodingtannergooding commented Apr 7, 2021•
edited
Loading

Copy link
Copy Markdown
Member

This resolves#36160

In order for this to work, GenTreeJitIntrinsic was updated to track the baseType as a CorInfoType rather than as a var_types (as discussed in #36160 (comment)). There is additionally a new JitType2PreciseVarType method which ensures that a CorInfoType is converted to a var_types in a way that preserves the sign (JITtype2varType will convert CORINFO_TYPE_UINT to CORINFO_TYPE_INT otherwise).

I ran jit-diff --pmi for --frameworks, --benchmarks, and --tests after the second commit to ensure there were no diffs due to the above changes. I then added the three latter commits supporting Vector<nint> and Vector<nuint>.

Edit: The vast majority of the PR is hardware intrinsic tests being added via the NotSupported template (so they are auto-generated, like most of the hwintrinsic tests).
Review of the PR can be simplified by just reviewing one of the generated tests since they all follow the same pattern.

Edit: This work was completed:
I am marking this as a draft until I can get some more tests up, including negative validating for nint/nuint on Vector64/128/256<T>.
I will also take a look at updating the couple places where we still have using nuint_t = System.UInt64, such as in Utf16Utility.Validation.cs

@ghost

ghost commented Apr 7, 2021

Copy link
Copy Markdown

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

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

@ghostghost added area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI new-api-needs-documentation labels Apr 7, 2021
@tannergooding
tannergoodingforce-pushed the intrinsic-type branch 3 times, most recently from b686f43 to f3be3d6CompareApril 7, 2021 22:12
@tannergooding
tannergoodingforce-pushed the intrinsic-type branch 2 times, most recently from 3053f08 to 755f6e0CompareApril 8, 2021 02:30
@tannergooding

tannergooding commented Apr 8, 2021•
edited
Loading

Copy link
Copy Markdown
MemberAuthor

@fanyang-mono, could you assist with the mono failures here?

It looks like there are two kinds of failures:

  1. Mono isn't correctly treating Vector128<nint>.Zero as unsupported
  2. Mono is faulting in src/mono/mono/mini/simd-intrinsics.c due to an assertion that shouldn't be reached (looks like its not handling the MONO_TYPE_ for nint and nuint).

Related, it looks like Mono has some hard-coded logic around ThrowForUnsupportedVectorBaseType (in src/mono/mono/mini/intrinsics.c) and that is being renamed/split into two methods for this PR.

The latter two issues look fairly straightforward to resolve, I'm just not familiar with what the correct MONO_TYPE_ is for nint or nuint.
The first issue I'm not sure where to start looking.

@fanyang-mono

fanyang-mono commented Apr 8, 2021

Copy link
Copy Markdown
Member

@fanyang-mono, could you assist with the mono failures here?

It looks like there are two kinds of failures:

  1. Mono isn't correctly treating Vector128<nint>.Zero as unsupported
  2. Mono is faulting in src/mono/mono/mini/simd-intrinsics.c due to an assertion that shouldn't be reached (looks like its not handling the MONO_TYPE_ for nint and nuint).

Related, it looks like Mono has some hard-coded logic around ThrowForUnsupportedVectorBaseType (in src/mono/mono/mini/intrinsics.c) and that is being renamed/split into two methods for this PR.

The latter two issues look fairly straightforward to resolve, I'm just not familiar with what the correct MONO_TYPE_ is for nint or nuint.
The first issue I'm not sure where to start looking.

nint and nuint is currently not support by mono. @vargaz Zoltan, could you please provide a little more details, if there is any?

@tannergooding

tannergooding commented Apr 8, 2021

Copy link
Copy Markdown
MemberAuthor

nint and nuint is currently not support by mono

I'm not sure I understand this, they are just aliases for System.IntPtr and System.UIntPtr as far as the JIT type system is concerned?

@vargaz

vargaz commented Apr 8, 2021

Copy link
Copy Markdown
Contributor

IntPtr/UIntPtr is MONO_TYPE_I/MONO_TYPE_U.

@fanyang-mono

fanyang-mono commented Apr 8, 2021

Copy link
Copy Markdown
Member

nint and nuint is currently not support by mono

I'm not sure I understand this, they are just aliases for System.IntPtr and System.UIntPtr as far as the JIT type system is concerned?

If that's the case, they should be mapped to MONO_TYPE_I and MONO_TYPE_U. Sorry that I misunderstood them with struct types.

@tannergooding

tannergooding commented Apr 8, 2021•
edited
Loading

Copy link
Copy Markdown
MemberAuthor

I believe I've fixed the first issue (70432e5):

Mono isn't correctly treating Vector128.Zero as unsupported

and the third issue (c3107e0):

it looks like Mono has some hard-coded logic around ThrowForUnsupportedVectorBaseType (in src/mono/mono/mini/intrinsics.c) and that is being renamed/split into two methods for this PR.

I've also fixed part of the second issue (also c3107e0):

Mono is faulting in src/mono/mono/mini/simd-intrinsics.c due to an assertion that shouldn't be reached (looks like its not handling the MONO_TYPE_ for nint and nuint).

The remainder of the second issue looks to be that a couple code paths will still assert (type_to_expand_op, type_to_insert_op, and type_to_extract_var_op) since MONO_TYPE_I8 and MONO_TYPE_U8 aren't handled.
It isn't clear if this is better handled by picking an existing op (e.g. OP_EXPAND_I4 when targeting 32-bit and OP_EXPAND_I8 when targeting 64-bit) or if it is better to add a new op (e.g. OP_EXPAND_I) and plumb the handling through.

@fanyang-mono

fanyang-mono commented Apr 8, 2021

Copy link
Copy Markdown
Member

I believe I've fixed the first issue (70432e5):

Mono isn't correctly treating Vector128.Zero as unsupported

and the third issue (c3107e0):

it looks like Mono has some hard-coded logic around ThrowForUnsupportedVectorBaseType (in src/mono/mono/mini/intrinsics.c) and that is being renamed/split into two methods for this PR.

I've also fixed part of the second issue (also c3107e0):

Mono is faulting in src/mono/mono/mini/simd-intrinsics.c due to an assertion that shouldn't be reached (looks like its not handling the MONO_TYPE_ for nint and nuint).

The remainder of the second issue looks to be that a couple code paths will still assert (type_to_expand_op, type_to_insert_op, and type_to_extract_var_op) since MONO_TYPE_I8 and MONO_TYPE_U8 aren't handled.
It isn't clear if this is better handled by picking an existing op (e.g. OP_EXPAND_I4 when targeting 32-bit and OP_EXPAND_I8 when targeting 64-bit) or if it is better to add a new op (e.g. OP_EXPAND_I) and plumb the handling through.

Maybe something like this

case MONO_TYPE_I:
#if TARGET_SIZEOF_VOID_P == 8
<treat it the same as I8>
#else
<treat it as I4>
#endif

@tannergooding

tannergooding commented Apr 8, 2021•
edited
Loading

Copy link
Copy Markdown
MemberAuthor

I believe the relevant mono paths are now updated to correctly handle Vector<nint> and Vector<nuint> and to block the same for Vector64/128/256<T> (at least until we take those to API review and hopefully unblock them as well). Hopefully CI passes now, thanks for the help! 😄

@tannergooding
tannergooding marked this pull request as ready for review April 8, 2021 21:44
@tannergooding

tannergooding commented Apr 8, 2021

Copy link
Copy Markdown
MemberAuthor

CC. @echesakovMSFT, @dotnet/jit-contrib for review

@JulieLeeMSFTJulieLeeMSFT added this to the 6.0.0 milestone Apr 8, 2021
@lambdageek

lambdageek commented Apr 8, 2021

Copy link
Copy Markdown
Member

@vargaz could you review the mono commit 8eb6fe9

@vargaz

vargaz commented Apr 9, 2021

Copy link
Copy Markdown
Contributor

The mono changes look ok to me.

This was referenced Apr 9, 2021
Closed
Closed
@tannergooding
Updating the Vector64/128/256<T> tests to have NotSupported validatio…
ed5db1f
…n for nint/nuint
@tannergooding
Splitting ThrowHelper.ThrowForUnsupportedVectorBaseType into separate…
35764d7
… functions for Numerics vs Intrinsics
@tannergooding
Updating Utf16Utility.Validation to directly use Vector<nuint>
57fc73d
@tannergooding
Don't use the auxiliary type to hold a SIMD type, since it can be tri…
3d4fe63
…vially pulled from the operand instead
@tannergooding
Split the mono handling for ThrowForUnsupportedVectorBaseType into Th…
fa2d443
…rowForUnsupportedNumericsVectorBaseType and ThrowForUnsupportedIntrinsicsVectorBaseType
@tannergooding
Add basic handling for MONO_TYPE_I and MONO_TYPE_U to simd-intrinsics.c
18c2c1a
@tannergooding
Ensure simd-intrinsics.c in Mono handles MONO_TYPE_I and `MONO_TYPE…
b311562
…_U` on relevant code paths
@tannergooding
Ensure we don't assert when encountering synthesized Vector128<nint> …
c150826
…handles
@tannergooding

tannergooding commented Apr 14, 2021

Copy link
Copy Markdown
MemberAuthor

Rebased to resolve a conflict, believe I've also resolved the remaining ARM64 issue (it passed on my Windows box).

@tannergooding

tannergooding commented Apr 15, 2021

Copy link
Copy Markdown
MemberAuthor

The mono changes look ok to me.

@vargaz, I had to push another commit for Mono: 0f4764d

A bit of the handling existed in mini-amd64.c and so was missed in my first pass, but caught by the tests.
I think I've gotten it all this time, but we'll see what CI says 😄

@tannergooding

tannergooding commented Apr 15, 2021

Copy link
Copy Markdown
MemberAuthor

Everything is passing now except for two LLVM AOT scenarios. It isn't clear to me what's wrong here given that the regular Mono leg passed.

@vargaz or @fanyang-mono, could you provide some guidance on how to root cause the failure here?

@tannergooding

tannergooding commented Apr 15, 2021

Copy link
Copy Markdown
MemberAuthor

Actually, I may have found it, there is a single line calling out an assert about halfway through the log:

  • Assertion: should not be reached at /__w/1/s/src/mono/mono/mini/mini-llvm.c:580

@tannergooding

tannergooding commented Apr 16, 2021

Copy link
Copy Markdown
MemberAuthor

Only test failures are unrelated and due to #51346

This should be ready for final review/merge.

@GrabYourPitchforks

GrabYourPitchforks commented Apr 17, 2021

Copy link
Copy Markdown
Member

My small contribution to the review: commit 57fc73d LGTM!

echesakov
echesakov approved these changes Apr 20, 2021
View reviewed changes

@echesakovechesakov left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM
Thank you for your contribution, @tannergooding!

cc @dotnet/jit-contrib

@tannergooding
tannergooding merged commit 17506ca into dotnet:mainApr 20, 2021
This was referenced Apr 21, 2021
Closed
Merged
@JulieLeeMSFTJulieLeeMSFT mentioned this pull request Apr 27, 2021
Closed
@AntonLapounovAntonLapounov mentioned this pull request Apr 28, 2021
Closed
@ghostghost locked as resolved and limited conversation to collaborators May 20, 2021
@tannergooding
tannergooding deleted the intrinsic-type branch July 1, 2025 14:39
Sign up for freeto subscribe to this conversation on GitHub. Already have an account? Sign in.

Reviewers

@CoffeeFluxCoffeeFluxAwaiting requested review from CoffeeFlux
@lambdageeklambdageekAwaiting requested review from lambdageek
@SamMonoRTSamMonoRTAwaiting requested review from SamMonoRT
@vargazvargazAwaiting requested review from vargaz
@EgorBoEgorBoAwaiting requested review from EgorBo
@imhameedimhameedAwaiting requested review from imhameed
1 more reviewer
@echesakovechesakovechesakov approved these changes
Reviewers whose approvals may not affect merge requirements

Assignees

@tannergoodingtannergooding

Labels

area-CodeGen-coreclrCLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI

Projects

None yet

Milestone

6.0.0

Development

Successfully merging this pull request may close these issues.

Consider expanding Vector<T> to support nint and nuint

7 participants

@tannergooding@fanyang-mono@vargaz@lambdageek@GrabYourPitchforks@echesakov@JulieLeeMSFT
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Add copy buttons to all 
 blocks\n(function() {\n function addCopyButtons() {\n document.querySelectorAll('pre code').forEach(function(codeBlock) {\n if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;\n codeBlock.parentElement.setAttribute('data-copy-added', 'true');\n \n var btn = document.createElement('button');\n btn.textContent = 'Copy';\n btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';\n btn.onmouseover = function() { this.style.opacity = '1'; };\n btn.onmouseout = function() { this.style.opacity = '0.7'; };\n btn.onclick = function() {\n navigator.clipboard.writeText(codeBlock.textContent).then(function() {\n btn.textContent = 'Copied!';\n setTimeout(function() { btn.textContent = 'Copy'; }, 1500);\n });\n };\n codeBlock.parentElement.style.position = 'relative';\n codeBlock.parentElement.appendChild(btn);\n });\n }\n \n addCopyButtons();\n \n // Re-run on dynamic content\n var observer = new MutationObserver(addCopyButtons);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Add Copy Buttons to Code Blocks");
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '

Skip to content
Updating Vector<T> to support nint and nuint - #50832
Merged
tannergooding merged 19 commits into
dotnet:mainfrom 
tannergooding:intrinsic-type
Apr 20, 2021
Merged
Updating Vector<T> to support nint and nuint#50832
tannergooding merged 19 commits into
dotnet:mainfrom 
tannergooding:intrinsic-type
Conversation
@tannergooding
@tannergoodingtannergooding
commented
Apr 7, 2021•

edited

Loading

Copy link


Copy Markdown

Member
This resolves#36160
In order for this to work, GenTreeJitIntrinsic was updated to track the baseType as a CorInfoType rather than as a var_types (as discussed in #36160 (comment)). There is additionally a new JitType2PreciseVarType method which ensures that a CorInfoType is converted to a var_types in a way that preserves the sign (JITtype2varType will convert CORINFO_TYPE_UINT to CORINFO_TYPE_INT otherwise).
I ran jit-diff --pmi for --frameworks, --benchmarks, and --tests after the second commit to ensure there were no diffs due to the above changes. I then added the three latter commits supporting Vector<nint> and Vector<nuint>.
Edit: The vast majority of the PR is hardware intrinsic tests being added via the NotSupported template (so they are auto-generated, like most of the hwintrinsic tests).

Review of the PR can be simplified by just reviewing one of the generated tests since they all follow the same pattern.
Edit: This work was completed:
I am marking this as a draft until I can get some more tests up, including negative validating for nint/nuint on Vector64/128/256<T>.
I will also take a look at updating the couple places where we still have using nuint_t = System.UInt64, such as in Utf16Utility.Validation.cs
@ghost
ghost
commented
Apr 7, 2021

Copy link


Copy Markdown

Note regarding the new-api-needs-documentation label:
This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.
@ghostghost
added

area-CodeGen-coreclr
CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI
new-api-needs-documentation

labels
Apr 7, 2021
@tannergooding
tannergoodingforce-pushed
the
intrinsic-type
branch
3 times, most recently
from
b686f43 to
f3be3d6CompareApril 7, 2021 22:12
@tannergooding
tannergoodingforce-pushed
the
intrinsic-type
branch
2 times, most recently
from
3053f08 to
755f6e0CompareApril 8, 2021 02:30
@tannergooding
tannergooding
commented
Apr 8, 2021•

edited

Loading

Copy link


Copy Markdown

MemberAuthor
@fanyang-mono, could you assist with the mono failures here?
It looks like there are two kinds of failures:
  1. Mono isn't correctly treating Vector128<nint>.Zero as unsupported
  2. Mono is faulting in src/mono/mono/mini/simd-intrinsics.c due to an assertion that shouldn't be reached (looks like its not handling the MONO_TYPE_ for nint and nuint).
Related, it looks like Mono has some hard-coded logic around ThrowForUnsupportedVectorBaseType (in src/mono/mono/mini/intrinsics.c) and that is being renamed/split into two methods for this PR.
The latter two issues look fairly straightforward to resolve, I'm just not familiar with what the correct MONO_TYPE_ is for nint or nuint.

The first issue I'm not sure where to start looking.
@fanyang-mono
fanyang-mono
commented
Apr 8, 2021

Copy link


Copy Markdown

Member
@fanyang-mono, could you assist with the mono failures here?
It looks like there are two kinds of failures:
  1. Mono isn't correctly treating Vector128<nint>.Zero as unsupported
  2. Mono is faulting in src/mono/mono/mini/simd-intrinsics.c due to an assertion that shouldn't be reached (looks like its not handling the MONO_TYPE_ for nint and nuint).
Related, it looks like Mono has some hard-coded logic around ThrowForUnsupportedVectorBaseType (in src/mono/mono/mini/intrinsics.c) and that is being renamed/split into two methods for this PR.
The latter two issues look fairly straightforward to resolve, I'm just not familiar with what the correct MONO_TYPE_ is for nint or nuint.

The first issue I'm not sure where to start looking.
nint and nuint is currently not support by mono. @vargaz Zoltan, could you please provide a little more details, if there is any?
@tannergooding
tannergooding
commented
Apr 8, 2021

Copy link


Copy Markdown

MemberAuthor
nint and nuint is currently not support by mono
I'm not sure I understand this, they are just aliases for System.IntPtr and System.UIntPtr as far as the JIT type system is concerned?
@vargaz
vargaz
commented
Apr 8, 2021

Copy link


Copy Markdown

Contributor
IntPtr/UIntPtr is MONO_TYPE_I/MONO_TYPE_U.
@fanyang-mono
fanyang-mono
commented
Apr 8, 2021

Copy link


Copy Markdown

Member
nint and nuint is currently not support by mono
I'm not sure I understand this, they are just aliases for System.IntPtr and System.UIntPtr as far as the JIT type system is concerned?
If that's the case, they should be mapped to MONO_TYPE_I and MONO_TYPE_U. Sorry that I misunderstood them with struct types.
@tannergooding
tannergooding
commented
Apr 8, 2021•

edited

Loading

Copy link


Copy Markdown

MemberAuthor
I believe I've fixed the first issue (70432e5):
Mono isn't correctly treating Vector128.Zero as unsupported
and the third issue (c3107e0):
it looks like Mono has some hard-coded logic around ThrowForUnsupportedVectorBaseType (in src/mono/mono/mini/intrinsics.c) and that is being renamed/split into two methods for this PR.
I've also fixed part of the second issue (also c3107e0):
Mono is faulting in src/mono/mono/mini/simd-intrinsics.c due to an assertion that shouldn't be reached (looks like its not handling the MONO_TYPE_ for nint and nuint).
The remainder of the second issue looks to be that a couple code paths will still assert (type_to_expand_op, type_to_insert_op, and type_to_extract_var_op) since MONO_TYPE_I8 and MONO_TYPE_U8 aren't handled.

It isn't clear if this is better handled by picking an existing op (e.g. OP_EXPAND_I4 when targeting 32-bit and OP_EXPAND_I8 when targeting 64-bit) or if it is better to add a new op (e.g. OP_EXPAND_I) and plumb the handling through.
@fanyang-mono
fanyang-mono
commented
Apr 8, 2021

Copy link


Copy Markdown

Member
I believe I've fixed the first issue (70432e5):
Mono isn't correctly treating Vector128.Zero as unsupported
and the third issue (c3107e0):
it looks like Mono has some hard-coded logic around ThrowForUnsupportedVectorBaseType (in src/mono/mono/mini/intrinsics.c) and that is being renamed/split into two methods for this PR.
I've also fixed part of the second issue (also c3107e0):
Mono is faulting in src/mono/mono/mini/simd-intrinsics.c due to an assertion that shouldn't be reached (looks like its not handling the MONO_TYPE_ for nint and nuint).
The remainder of the second issue looks to be that a couple code paths will still assert (type_to_expand_op, type_to_insert_op, and type_to_extract_var_op) since MONO_TYPE_I8 and MONO_TYPE_U8 aren't handled.

It isn't clear if this is better handled by picking an existing op (e.g. OP_EXPAND_I4 when targeting 32-bit and OP_EXPAND_I8 when targeting 64-bit) or if it is better to add a new op (e.g. OP_EXPAND_I) and plumb the handling through.
Maybe something like this
case MONO_TYPE_I:
#if TARGET_SIZEOF_VOID_P == 8
<treat it the same as I8>
#else
<treat it as I4>
#endif

@tannergooding
tannergooding
commented
Apr 8, 2021•

edited

Loading

Copy link


Copy Markdown

MemberAuthor
I believe the relevant mono paths are now updated to correctly handle Vector<nint> and Vector<nuint> and to block the same for Vector64/128/256<T> (at least until we take those to API review and hopefully unblock them as well). Hopefully CI passes now, thanks for the help! 😄
@tannergooding
tannergooding
marked this pull request as ready for review
April 8, 2021 21:44
@tannergooding
tannergooding
commented
Apr 8, 2021

Copy link


Copy Markdown

MemberAuthor
CC. @echesakovMSFT, @dotnet/jit-contrib for review
@JulieLeeMSFTJulieLeeMSFT
added this to the 6.0.0 milestone
Apr 8, 2021
@lambdageek
lambdageek
commented
Apr 8, 2021

Copy link


Copy Markdown

Member
@vargaz could you review the mono commit 8eb6fe9
@vargaz
vargaz
commented
Apr 9, 2021

Copy link


Copy Markdown

Contributor
The mono changes look ok to me.

This was referenced Apr 9, 2021

Closed


Closed

@tannergooding
Updating the Vector64/128/256<T> tests to have NotSupported validatio…
ed5db1f
…n for nint/nuint
@tannergooding
Splitting ThrowHelper.ThrowForUnsupportedVectorBaseType into separate…
35764d7
… functions for Numerics vs Intrinsics
@tannergooding
Updating Utf16Utility.Validation to directly use Vector<nuint>
57fc73d
@tannergooding
Don't use the auxiliary type to hold a SIMD type, since it can be tri…
3d4fe63
…vially pulled from the operand instead
@tannergooding
Split the mono handling for ThrowForUnsupportedVectorBaseType into Th…
fa2d443
…rowForUnsupportedNumericsVectorBaseType and ThrowForUnsupportedIntrinsicsVectorBaseType
@tannergooding
Add basic handling for MONO_TYPE_I and MONO_TYPE_U to simd-intrinsics.c
18c2c1a
@tannergooding
Ensure simd-intrinsics.c in Mono handles MONO_TYPE_I and `MONO_TYPE…
b311562
…_U` on relevant code paths
@tannergooding
Ensure we don't assert when encountering synthesized Vector128<nint> …
c150826
…handles
@tannergooding
tannergooding
commented
Apr 14, 2021

Copy link


Copy Markdown

MemberAuthor
Rebased to resolve a conflict, believe I've also resolved the remaining ARM64 issue (it passed on my Windows box).
@tannergooding
tannergooding
commented
Apr 15, 2021

Copy link


Copy Markdown

MemberAuthor
The mono changes look ok to me.
@vargaz, I had to push another commit for Mono: 0f4764d
A bit of the handling existed in mini-amd64.c and so was missed in my first pass, but caught by the tests.

I think I've gotten it all this time, but we'll see what CI says 😄
@tannergooding
tannergooding
commented
Apr 15, 2021

Copy link


Copy Markdown

MemberAuthor
Everything is passing now except for two LLVM AOT scenarios. It isn't clear to me what's wrong here given that the regular Mono leg passed.
@vargaz or @fanyang-mono, could you provide some guidance on how to root cause the failure here?
@tannergooding
tannergooding
commented
Apr 15, 2021

Copy link


Copy Markdown

MemberAuthor
Actually, I may have found it, there is a single line calling out an assert about halfway through the log:
  • Assertion: should not be reached at /__w/1/s/src/mono/mono/mini/mini-llvm.c:580
@tannergooding
tannergooding
commented
Apr 16, 2021

Copy link


Copy Markdown

MemberAuthor
Only test failures are unrelated and due to #51346
This should be ready for final review/merge.
@GrabYourPitchforks
GrabYourPitchforks
commented
Apr 17, 2021

Copy link


Copy Markdown

Member
My small contribution to the review: commit 57fc73d LGTM!
echesakov
echesakov
approved these changes
Apr 20, 2021
View reviewed changes
@echesakovechesakov
left a comment


Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Thank you for your contribution, @tannergooding!
cc @dotnet/jit-contrib
@tannergooding
tannergooding
merged commit 17506ca
into
dotnet:mainApr 20, 2021

This was referenced Apr 21, 2021

Closed

 Merged

@JulieLeeMSFTJulieLeeMSFT
mentioned this pull request
Apr 27, 2021

Closed

@AntonLapounovAntonLapounov
mentioned this pull request
Apr 28, 2021
 Closed

@ghostghost
locked as resolved and limited conversation to collaborators
May 20, 2021
@tannergooding
tannergooding
deleted the

intrinsic-type

branch
July 1, 2025 14:39
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers

@CoffeeFluxCoffeeFluxAwaiting requested review from CoffeeFlux
@lambdageeklambdageekAwaiting requested review from lambdageek
@SamMonoRTSamMonoRTAwaiting requested review from SamMonoRT
@vargazvargazAwaiting requested review from vargaz
@EgorBoEgorBoAwaiting requested review from EgorBo
@imhameedimhameedAwaiting requested review from imhameed

1 more reviewer

@echesakovechesakovechesakov approved these changes
Reviewers whose approvals may not affect merge requirements

Assignees

@tannergoodingtannergooding

Labels

area-CodeGen-coreclrCLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI

Projects


None yet


Milestone

6.0.0

Development

Successfully merging this pull request may close these issues.

Consider expanding Vector<T> to support nint and nuint

7 participants

@tannergooding@fanyang-mono@vargaz@lambdageek@GrabYourPitchforks@echesakov@JulieLeeMSFT

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Force GitHub README to respect dark mode\n(function() {\n var style = document.createElement('style');\n style.textContent = '\n .markdown-body {\n color-scheme: dark light;\n }\n .markdown-body pre { background: #161b22 !important; }\n .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }\n .markdown-body table th, .markdown-body table td { border-color: #30363d !important; }\n .markdown-body img { background: #0d1117; }\n .markdown-body blockquote { border-left-color: #8b949e; }\n .markdown-body hr { border-color: #30363d; }\n ';\n document.head.appendChild(style);\n})();", "GitHub Dark Mode README Fix");
}
} catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
Updating Vector<T> to support nint and nuint - #50832
Merged
tannergooding merged 19 commits into
dotnet:mainfrom 
tannergooding:intrinsic-type
Apr 20, 2021
Merged
Updating Vector<T> to support nint and nuint#50832
tannergooding merged 19 commits into
dotnet:mainfrom 
tannergooding:intrinsic-type
Conversation
@tannergooding
@tannergoodingtannergooding
commented
Apr 7, 2021•

edited

Loading

Copy link


Copy Markdown

Member
This resolves#36160
In order for this to work, GenTreeJitIntrinsic was updated to track the baseType as a CorInfoType rather than as a var_types (as discussed in #36160 (comment)). There is additionally a new JitType2PreciseVarType method which ensures that a CorInfoType is converted to a var_types in a way that preserves the sign (JITtype2varType will convert CORINFO_TYPE_UINT to CORINFO_TYPE_INT otherwise).
I ran jit-diff --pmi for --frameworks, --benchmarks, and --tests after the second commit to ensure there were no diffs due to the above changes. I then added the three latter commits supporting Vector<nint> and Vector<nuint>.
Edit: The vast majority of the PR is hardware intrinsic tests being added via the NotSupported template (so they are auto-generated, like most of the hwintrinsic tests).

Review of the PR can be simplified by just reviewing one of the generated tests since they all follow the same pattern.
Edit: This work was completed:
I am marking this as a draft until I can get some more tests up, including negative validating for nint/nuint on Vector64/128/256<T>.
I will also take a look at updating the couple places where we still have using nuint_t = System.UInt64, such as in Utf16Utility.Validation.cs
@ghost
ghost
commented
Apr 7, 2021

Copy link


Copy Markdown

Note regarding the new-api-needs-documentation label:
This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.
@ghostghost
added

area-CodeGen-coreclr
CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI
new-api-needs-documentation

labels
Apr 7, 2021
@tannergooding
tannergoodingforce-pushed
the
intrinsic-type
branch
3 times, most recently
from
b686f43 to
f3be3d6CompareApril 7, 2021 22:12
@tannergooding
tannergoodingforce-pushed
the
intrinsic-type
branch
2 times, most recently
from
3053f08 to
755f6e0CompareApril 8, 2021 02:30
@tannergooding
tannergooding
commented
Apr 8, 2021•

edited

Loading

Copy link


Copy Markdown

MemberAuthor
@fanyang-mono, could you assist with the mono failures here?
It looks like there are two kinds of failures:
  1. Mono isn't correctly treating Vector128<nint>.Zero as unsupported
  2. Mono is faulting in src/mono/mono/mini/simd-intrinsics.c due to an assertion that shouldn't be reached (looks like its not handling the MONO_TYPE_ for nint and nuint).
Related, it looks like Mono has some hard-coded logic around ThrowForUnsupportedVectorBaseType (in src/mono/mono/mini/intrinsics.c) and that is being renamed/split into two methods for this PR.
The latter two issues look fairly straightforward to resolve, I'm just not familiar with what the correct MONO_TYPE_ is for nint or nuint.

The first issue I'm not sure where to start looking.
@fanyang-mono
fanyang-mono
commented
Apr 8, 2021

Copy link


Copy Markdown

Member
@fanyang-mono, could you assist with the mono failures here?
It looks like there are two kinds of failures:
  1. Mono isn't correctly treating Vector128<nint>.Zero as unsupported
  2. Mono is faulting in src/mono/mono/mini/simd-intrinsics.c due to an assertion that shouldn't be reached (looks like its not handling the MONO_TYPE_ for nint and nuint).
Related, it looks like Mono has some hard-coded logic around ThrowForUnsupportedVectorBaseType (in src/mono/mono/mini/intrinsics.c) and that is being renamed/split into two methods for this PR.
The latter two issues look fairly straightforward to resolve, I'm just not familiar with what the correct MONO_TYPE_ is for nint or nuint.

The first issue I'm not sure where to start looking.
nint and nuint is currently not support by mono. @vargaz Zoltan, could you please provide a little more details, if there is any?
@tannergooding
tannergooding
commented
Apr 8, 2021

Copy link


Copy Markdown

MemberAuthor
nint and nuint is currently not support by mono
I'm not sure I understand this, they are just aliases for System.IntPtr and System.UIntPtr as far as the JIT type system is concerned?
@vargaz
vargaz
commented
Apr 8, 2021

Copy link


Copy Markdown

Contributor
IntPtr/UIntPtr is MONO_TYPE_I/MONO_TYPE_U.
@fanyang-mono
fanyang-mono
commented
Apr 8, 2021

Copy link


Copy Markdown

Member
nint and nuint is currently not support by mono
I'm not sure I understand this, they are just aliases for System.IntPtr and System.UIntPtr as far as the JIT type system is concerned?
If that's the case, they should be mapped to MONO_TYPE_I and MONO_TYPE_U. Sorry that I misunderstood them with struct types.
@tannergooding
tannergooding
commented
Apr 8, 2021•

edited

Loading

Copy link


Copy Markdown

MemberAuthor
I believe I've fixed the first issue (70432e5):
Mono isn't correctly treating Vector128.Zero as unsupported
and the third issue (c3107e0):
it looks like Mono has some hard-coded logic around ThrowForUnsupportedVectorBaseType (in src/mono/mono/mini/intrinsics.c) and that is being renamed/split into two methods for this PR.
I've also fixed part of the second issue (also c3107e0):
Mono is faulting in src/mono/mono/mini/simd-intrinsics.c due to an assertion that shouldn't be reached (looks like its not handling the MONO_TYPE_ for nint and nuint).
The remainder of the second issue looks to be that a couple code paths will still assert (type_to_expand_op, type_to_insert_op, and type_to_extract_var_op) since MONO_TYPE_I8 and MONO_TYPE_U8 aren't handled.

It isn't clear if this is better handled by picking an existing op (e.g. OP_EXPAND_I4 when targeting 32-bit and OP_EXPAND_I8 when targeting 64-bit) or if it is better to add a new op (e.g. OP_EXPAND_I) and plumb the handling through.
@fanyang-mono
fanyang-mono
commented
Apr 8, 2021

Copy link


Copy Markdown

Member
I believe I've fixed the first issue (70432e5):
Mono isn't correctly treating Vector128.Zero as unsupported
and the third issue (c3107e0):
it looks like Mono has some hard-coded logic around ThrowForUnsupportedVectorBaseType (in src/mono/mono/mini/intrinsics.c) and that is being renamed/split into two methods for this PR.
I've also fixed part of the second issue (also c3107e0):
Mono is faulting in src/mono/mono/mini/simd-intrinsics.c due to an assertion that shouldn't be reached (looks like its not handling the MONO_TYPE_ for nint and nuint).
The remainder of the second issue looks to be that a couple code paths will still assert (type_to_expand_op, type_to_insert_op, and type_to_extract_var_op) since MONO_TYPE_I8 and MONO_TYPE_U8 aren't handled.

It isn't clear if this is better handled by picking an existing op (e.g. OP_EXPAND_I4 when targeting 32-bit and OP_EXPAND_I8 when targeting 64-bit) or if it is better to add a new op (e.g. OP_EXPAND_I) and plumb the handling through.
Maybe something like this
case MONO_TYPE_I:
#if TARGET_SIZEOF_VOID_P == 8
<treat it the same as I8>
#else
<treat it as I4>
#endif

@tannergooding
tannergooding
commented
Apr 8, 2021•

edited

Loading

Copy link


Copy Markdown

MemberAuthor
I believe the relevant mono paths are now updated to correctly handle Vector<nint> and Vector<nuint> and to block the same for Vector64/128/256<T> (at least until we take those to API review and hopefully unblock them as well). Hopefully CI passes now, thanks for the help! 😄
@tannergooding
tannergooding
marked this pull request as ready for review
April 8, 2021 21:44
@tannergooding
tannergooding
commented
Apr 8, 2021

Copy link


Copy Markdown

MemberAuthor
CC. @echesakovMSFT, @dotnet/jit-contrib for review
@JulieLeeMSFTJulieLeeMSFT
added this to the 6.0.0 milestone
Apr 8, 2021
@lambdageek
lambdageek
commented
Apr 8, 2021

Copy link


Copy Markdown

Member
@vargaz could you review the mono commit 8eb6fe9
@vargaz
vargaz
commented
Apr 9, 2021

Copy link


Copy Markdown

Contributor
The mono changes look ok to me.

This was referenced Apr 9, 2021

Closed


Closed

@tannergooding
Updating the Vector64/128/256<T> tests to have NotSupported validatio…
ed5db1f
…n for nint/nuint
@tannergooding
Splitting ThrowHelper.ThrowForUnsupportedVectorBaseType into separate…
35764d7
… functions for Numerics vs Intrinsics
@tannergooding
Updating Utf16Utility.Validation to directly use Vector<nuint>
57fc73d
@tannergooding
Don't use the auxiliary type to hold a SIMD type, since it can be tri…
3d4fe63
…vially pulled from the operand instead
@tannergooding
Split the mono handling for ThrowForUnsupportedVectorBaseType into Th…
fa2d443
…rowForUnsupportedNumericsVectorBaseType and ThrowForUnsupportedIntrinsicsVectorBaseType
@tannergooding
Add basic handling for MONO_TYPE_I and MONO_TYPE_U to simd-intrinsics.c
18c2c1a
@tannergooding
Ensure simd-intrinsics.c in Mono handles MONO_TYPE_I and `MONO_TYPE…
b311562
…_U` on relevant code paths
@tannergooding
Ensure we don't assert when encountering synthesized Vector128<nint> …
c150826
…handles
@tannergooding
tannergooding
commented
Apr 14, 2021

Copy link


Copy Markdown

MemberAuthor
Rebased to resolve a conflict, believe I've also resolved the remaining ARM64 issue (it passed on my Windows box).
@tannergooding
tannergooding
commented
Apr 15, 2021

Copy link


Copy Markdown

MemberAuthor
The mono changes look ok to me.
@vargaz, I had to push another commit for Mono: 0f4764d
A bit of the handling existed in mini-amd64.c and so was missed in my first pass, but caught by the tests.

I think I've gotten it all this time, but we'll see what CI says 😄
@tannergooding
tannergooding
commented
Apr 15, 2021

Copy link


Copy Markdown

MemberAuthor
Everything is passing now except for two LLVM AOT scenarios. It isn't clear to me what's wrong here given that the regular Mono leg passed.
@vargaz or @fanyang-mono, could you provide some guidance on how to root cause the failure here?
@tannergooding
tannergooding
commented
Apr 15, 2021

Copy link


Copy Markdown

MemberAuthor
Actually, I may have found it, there is a single line calling out an assert about halfway through the log:
  • Assertion: should not be reached at /__w/1/s/src/mono/mono/mini/mini-llvm.c:580
@tannergooding
tannergooding
commented
Apr 16, 2021

Copy link


Copy Markdown

MemberAuthor
Only test failures are unrelated and due to #51346
This should be ready for final review/merge.
@GrabYourPitchforks
GrabYourPitchforks
commented
Apr 17, 2021

Copy link


Copy Markdown

Member
My small contribution to the review: commit 57fc73d LGTM!
echesakov
echesakov
approved these changes
Apr 20, 2021
View reviewed changes
@echesakovechesakov
left a comment


Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Thank you for your contribution, @tannergooding!
cc @dotnet/jit-contrib
@tannergooding
tannergooding
merged commit 17506ca
into
dotnet:mainApr 20, 2021

This was referenced Apr 21, 2021

Closed

 Merged

@JulieLeeMSFTJulieLeeMSFT
mentioned this pull request
Apr 27, 2021

Closed

@AntonLapounovAntonLapounov
mentioned this pull request
Apr 28, 2021
 Closed

@ghostghost
locked as resolved and limited conversation to collaborators
May 20, 2021
@tannergooding
tannergooding
deleted the

intrinsic-type

branch
July 1, 2025 14:39
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers

@CoffeeFluxCoffeeFluxAwaiting requested review from CoffeeFlux
@lambdageeklambdageekAwaiting requested review from lambdageek
@SamMonoRTSamMonoRTAwaiting requested review from SamMonoRT
@vargazvargazAwaiting requested review from vargaz
@EgorBoEgorBoAwaiting requested review from EgorBo
@imhameedimhameedAwaiting requested review from imhameed

1 more reviewer

@echesakovechesakovechesakov approved these changes
Reviewers whose approvals may not affect merge requirements

Assignees

@tannergoodingtannergooding

Labels

area-CodeGen-coreclrCLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI

Projects


None yet


Milestone

6.0.0

Development

Successfully merging this pull request may close these issues.

Consider expanding Vector<T> to support nint and nuint

7 participants

@tannergooding@fanyang-mono@vargaz@lambdageek@GrabYourPitchforks@echesakov@JulieLeeMSFT

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Highlight search terms from Google/DuckDuckGo/Bing referrer\n(function() {\n var ref = document.referrer;\n var terms = [];\n \n if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {\n var url = new URL(ref);\n var q = url.searchParams.get('q') || url.searchParams.get('p');\n if (q) {\n terms = q.split(/\\s+/).filter(function(t) { return t.length > 2; });\n }\n }\n \n if (terms.length === 0) return;\n \n var style = document.createElement('style');\n style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';\n document.head.appendChild(style);\n \n function highlight(node) {\n if (node.nodeType === 3) { // text node\n var text = node.textContent;\n var found = false;\n terms.forEach(function(term) {\n var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\') + ')', 'gi');\n if (regex.test(text)) {\n found = true;\n var frag = document.createDocumentFragment();\n var parts = text.split(regex);\n parts.forEach(function(part, i) {\n if (i % 2 === 0) {\n frag.appendChild(document.createTextNode(part));\n } else {\n var span = document.createElement('span');\n span.className = 'userscript-highlight';\n span.textContent = part;\n frag.appendChild(span);\n }\n });\n node.parentNode.replaceChild(frag, node);\n }\n });\n } else if (node.nodeType === 1 && node.childNodes) { // element\n var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];\n if (!skipTags.includes(node.tagName)) {\n Array.from(node.childNodes).forEach(highlight);\n }\n }\n }\n \n highlight(document.body);\n \n // Re-highlight on dynamic content\n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1 || node.nodeType === 3) highlight(node);\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Highlight Search Terms");
}
} catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
Updating Vector<T> to support nint and nuint - #50832
Merged
tannergooding merged 19 commits into
dotnet:mainfrom 
tannergooding:intrinsic-type
Apr 20, 2021
Merged
Updating Vector<T> to support nint and nuint#50832
tannergooding merged 19 commits into
dotnet:mainfrom 
tannergooding:intrinsic-type
Conversation
@tannergooding
@tannergoodingtannergooding
commented
Apr 7, 2021•

edited

Loading

Copy link


Copy Markdown

Member
This resolves#36160
In order for this to work, GenTreeJitIntrinsic was updated to track the baseType as a CorInfoType rather than as a var_types (as discussed in #36160 (comment)). There is additionally a new JitType2PreciseVarType method which ensures that a CorInfoType is converted to a var_types in a way that preserves the sign (JITtype2varType will convert CORINFO_TYPE_UINT to CORINFO_TYPE_INT otherwise).
I ran jit-diff --pmi for --frameworks, --benchmarks, and --tests after the second commit to ensure there were no diffs due to the above changes. I then added the three latter commits supporting Vector<nint> and Vector<nuint>.
Edit: The vast majority of the PR is hardware intrinsic tests being added via the NotSupported template (so they are auto-generated, like most of the hwintrinsic tests).

Review of the PR can be simplified by just reviewing one of the generated tests since they all follow the same pattern.
Edit: This work was completed:
I am marking this as a draft until I can get some more tests up, including negative validating for nint/nuint on Vector64/128/256<T>.
I will also take a look at updating the couple places where we still have using nuint_t = System.UInt64, such as in Utf16Utility.Validation.cs
@ghost
ghost
commented
Apr 7, 2021

Copy link


Copy Markdown

Note regarding the new-api-needs-documentation label:
This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.
@ghostghost
added

area-CodeGen-coreclr
CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI
new-api-needs-documentation

labels
Apr 7, 2021
@tannergooding
tannergoodingforce-pushed
the
intrinsic-type
branch
3 times, most recently
from
b686f43 to
f3be3d6CompareApril 7, 2021 22:12
@tannergooding
tannergoodingforce-pushed
the
intrinsic-type
branch
2 times, most recently
from
3053f08 to
755f6e0CompareApril 8, 2021 02:30
@tannergooding
tannergooding
commented
Apr 8, 2021•

edited

Loading

Copy link


Copy Markdown

MemberAuthor
@fanyang-mono, could you assist with the mono failures here?
It looks like there are two kinds of failures:
  1. Mono isn't correctly treating Vector128<nint>.Zero as unsupported
  2. Mono is faulting in src/mono/mono/mini/simd-intrinsics.c due to an assertion that shouldn't be reached (looks like its not handling the MONO_TYPE_ for nint and nuint).
Related, it looks like Mono has some hard-coded logic around ThrowForUnsupportedVectorBaseType (in src/mono/mono/mini/intrinsics.c) and that is being renamed/split into two methods for this PR.
The latter two issues look fairly straightforward to resolve, I'm just not familiar with what the correct MONO_TYPE_ is for nint or nuint.

The first issue I'm not sure where to start looking.
@fanyang-mono
fanyang-mono
commented
Apr 8, 2021

Copy link


Copy Markdown

Member
@fanyang-mono, could you assist with the mono failures here?
It looks like there are two kinds of failures:
  1. Mono isn't correctly treating Vector128<nint>.Zero as unsupported
  2. Mono is faulting in src/mono/mono/mini/simd-intrinsics.c due to an assertion that shouldn't be reached (looks like its not handling the MONO_TYPE_ for nint and nuint).
Related, it looks like Mono has some hard-coded logic around ThrowForUnsupportedVectorBaseType (in src/mono/mono/mini/intrinsics.c) and that is being renamed/split into two methods for this PR.
The latter two issues look fairly straightforward to resolve, I'm just not familiar with what the correct MONO_TYPE_ is for nint or nuint.

The first issue I'm not sure where to start looking.
nint and nuint is currently not support by mono. @vargaz Zoltan, could you please provide a little more details, if there is any?
@tannergooding
tannergooding
commented
Apr 8, 2021

Copy link


Copy Markdown

MemberAuthor
nint and nuint is currently not support by mono
I'm not sure I understand this, they are just aliases for System.IntPtr and System.UIntPtr as far as the JIT type system is concerned?
@vargaz
vargaz
commented
Apr 8, 2021

Copy link


Copy Markdown

Contributor
IntPtr/UIntPtr is MONO_TYPE_I/MONO_TYPE_U.
@fanyang-mono
fanyang-mono
commented
Apr 8, 2021

Copy link


Copy Markdown

Member
nint and nuint is currently not support by mono
I'm not sure I understand this, they are just aliases for System.IntPtr and System.UIntPtr as far as the JIT type system is concerned?
If that's the case, they should be mapped to MONO_TYPE_I and MONO_TYPE_U. Sorry that I misunderstood them with struct types.
@tannergooding
tannergooding
commented
Apr 8, 2021•

edited

Loading

Copy link


Copy Markdown

MemberAuthor
I believe I've fixed the first issue (70432e5):
Mono isn't correctly treating Vector128.Zero as unsupported
and the third issue (c3107e0):
it looks like Mono has some hard-coded logic around ThrowForUnsupportedVectorBaseType (in src/mono/mono/mini/intrinsics.c) and that is being renamed/split into two methods for this PR.
I've also fixed part of the second issue (also c3107e0):
Mono is faulting in src/mono/mono/mini/simd-intrinsics.c due to an assertion that shouldn't be reached (looks like its not handling the MONO_TYPE_ for nint and nuint).
The remainder of the second issue looks to be that a couple code paths will still assert (type_to_expand_op, type_to_insert_op, and type_to_extract_var_op) since MONO_TYPE_I8 and MONO_TYPE_U8 aren't handled.

It isn't clear if this is better handled by picking an existing op (e.g. OP_EXPAND_I4 when targeting 32-bit and OP_EXPAND_I8 when targeting 64-bit) or if it is better to add a new op (e.g. OP_EXPAND_I) and plumb the handling through.
@fanyang-mono
fanyang-mono
commented
Apr 8, 2021

Copy link


Copy Markdown

Member
I believe I've fixed the first issue (70432e5):
Mono isn't correctly treating Vector128.Zero as unsupported
and the third issue (c3107e0):
it looks like Mono has some hard-coded logic around ThrowForUnsupportedVectorBaseType (in src/mono/mono/mini/intrinsics.c) and that is being renamed/split into two methods for this PR.
I've also fixed part of the second issue (also c3107e0):
Mono is faulting in src/mono/mono/mini/simd-intrinsics.c due to an assertion that shouldn't be reached (looks like its not handling the MONO_TYPE_ for nint and nuint).
The remainder of the second issue looks to be that a couple code paths will still assert (type_to_expand_op, type_to_insert_op, and type_to_extract_var_op) since MONO_TYPE_I8 and MONO_TYPE_U8 aren't handled.

It isn't clear if this is better handled by picking an existing op (e.g. OP_EXPAND_I4 when targeting 32-bit and OP_EXPAND_I8 when targeting 64-bit) or if it is better to add a new op (e.g. OP_EXPAND_I) and plumb the handling through.
Maybe something like this
case MONO_TYPE_I:
#if TARGET_SIZEOF_VOID_P == 8
<treat it the same as I8>
#else
<treat it as I4>
#endif

@tannergooding
tannergooding
commented
Apr 8, 2021•

edited

Loading

Copy link


Copy Markdown

MemberAuthor
I believe the relevant mono paths are now updated to correctly handle Vector<nint> and Vector<nuint> and to block the same for Vector64/128/256<T> (at least until we take those to API review and hopefully unblock them as well). Hopefully CI passes now, thanks for the help! 😄
@tannergooding
tannergooding
marked this pull request as ready for review
April 8, 2021 21:44
@tannergooding
tannergooding
commented
Apr 8, 2021

Copy link


Copy Markdown

MemberAuthor
CC. @echesakovMSFT, @dotnet/jit-contrib for review
@JulieLeeMSFTJulieLeeMSFT
added this to the 6.0.0 milestone
Apr 8, 2021
@lambdageek
lambdageek
commented
Apr 8, 2021

Copy link


Copy Markdown

Member
@vargaz could you review the mono commit 8eb6fe9
@vargaz
vargaz
commented
Apr 9, 2021

Copy link


Copy Markdown

Contributor
The mono changes look ok to me.

This was referenced Apr 9, 2021

Closed


Closed

@tannergooding
Updating the Vector64/128/256<T> tests to have NotSupported validatio…
ed5db1f
…n for nint/nuint
@tannergooding
Splitting ThrowHelper.ThrowForUnsupportedVectorBaseType into separate…
35764d7
… functions for Numerics vs Intrinsics
@tannergooding
Updating Utf16Utility.Validation to directly use Vector<nuint>
57fc73d
@tannergooding
Don't use the auxiliary type to hold a SIMD type, since it can be tri…
3d4fe63
…vially pulled from the operand instead
@tannergooding
Split the mono handling for ThrowForUnsupportedVectorBaseType into Th…
fa2d443
…rowForUnsupportedNumericsVectorBaseType and ThrowForUnsupportedIntrinsicsVectorBaseType
@tannergooding
Add basic handling for MONO_TYPE_I and MONO_TYPE_U to simd-intrinsics.c
18c2c1a
@tannergooding
Ensure simd-intrinsics.c in Mono handles MONO_TYPE_I and `MONO_TYPE…
b311562
…_U` on relevant code paths
@tannergooding
Ensure we don't assert when encountering synthesized Vector128<nint> …
c150826
…handles
@tannergooding
tannergooding
commented
Apr 14, 2021

Copy link


Copy Markdown

MemberAuthor
Rebased to resolve a conflict, believe I've also resolved the remaining ARM64 issue (it passed on my Windows box).
@tannergooding
tannergooding
commented
Apr 15, 2021

Copy link


Copy Markdown

MemberAuthor
The mono changes look ok to me.
@vargaz, I had to push another commit for Mono: 0f4764d
A bit of the handling existed in mini-amd64.c and so was missed in my first pass, but caught by the tests.

I think I've gotten it all this time, but we'll see what CI says 😄
@tannergooding
tannergooding
commented
Apr 15, 2021

Copy link


Copy Markdown

MemberAuthor
Everything is passing now except for two LLVM AOT scenarios. It isn't clear to me what's wrong here given that the regular Mono leg passed.
@vargaz or @fanyang-mono, could you provide some guidance on how to root cause the failure here?
@tannergooding
tannergooding
commented
Apr 15, 2021

Copy link


Copy Markdown

MemberAuthor
Actually, I may have found it, there is a single line calling out an assert about halfway through the log:
  • Assertion: should not be reached at /__w/1/s/src/mono/mono/mini/mini-llvm.c:580
@tannergooding
tannergooding
commented
Apr 16, 2021

Copy link


Copy Markdown

MemberAuthor
Only test failures are unrelated and due to #51346
This should be ready for final review/merge.
@GrabYourPitchforks
GrabYourPitchforks
commented
Apr 17, 2021

Copy link


Copy Markdown

Member
My small contribution to the review: commit 57fc73d LGTM!
echesakov
echesakov
approved these changes
Apr 20, 2021
View reviewed changes
@echesakovechesakov
left a comment


Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Thank you for your contribution, @tannergooding!
cc @dotnet/jit-contrib
@tannergooding
tannergooding
merged commit 17506ca
into
dotnet:mainApr 20, 2021

This was referenced Apr 21, 2021

Closed

 Merged

@JulieLeeMSFTJulieLeeMSFT
mentioned this pull request
Apr 27, 2021

Closed

@AntonLapounovAntonLapounov
mentioned this pull request
Apr 28, 2021
 Closed

@ghostghost
locked as resolved and limited conversation to collaborators
May 20, 2021
@tannergooding
tannergooding
deleted the

intrinsic-type

branch
July 1, 2025 14:39
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers

@CoffeeFluxCoffeeFluxAwaiting requested review from CoffeeFlux
@lambdageeklambdageekAwaiting requested review from lambdageek
@SamMonoRTSamMonoRTAwaiting requested review from SamMonoRT
@vargazvargazAwaiting requested review from vargaz
@EgorBoEgorBoAwaiting requested review from EgorBo
@imhameedimhameedAwaiting requested review from imhameed

1 more reviewer

@echesakovechesakovechesakov approved these changes
Reviewers whose approvals may not affect merge requirements

Assignees

@tannergoodingtannergooding

Labels

area-CodeGen-coreclrCLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI

Projects


None yet


Milestone

6.0.0

Development

Successfully merging this pull request may close these issues.

Consider expanding Vector<T> to support nint and nuint

7 participants

@tannergooding@fanyang-mono@vargaz@lambdageek@GrabYourPitchforks@echesakov@JulieLeeMSFT

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Strip utm_, fbclid, gclid, etc. from all links on page\n(function() {\n var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',\n 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',\n 'ref', 'ref_src', 'source', 'medium', 'campaign'];\n \n function cleanUrl(url) {\n try {\n var u = new URL(url, window.location.origin);\n var changed = false;\n trackingParams.forEach(function(p) {\n if (u.searchParams.has(p)) {\n u.searchParams.delete(p);\n changed = true;\n }\n });\n return changed ? u.toString() : url;\n } catch (e) {\n return url;\n }\n }\n \n function cleanLinks() {\n document.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n \n cleanLinks();\n \n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1) {\n if (node.tagName === 'A') cleanLinks();\n node.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Remove Tracking Parameters from Links");
}
} catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); }
})();
(function(){
try {
var __m = "youtube.com";
var __re = new RegExp('^' + "youtube\\.com" + '

Skip to content
Updating Vector<T> to support nint and nuint - #50832
Merged
tannergooding merged 19 commits into
dotnet:mainfrom 
tannergooding:intrinsic-type
Apr 20, 2021
Merged
Updating Vector<T> to support nint and nuint#50832
tannergooding merged 19 commits into
dotnet:mainfrom 
tannergooding:intrinsic-type
Conversation
@tannergooding
@tannergoodingtannergooding
commented
Apr 7, 2021•

edited

Loading

Copy link


Copy Markdown

Member
This resolves#36160
In order for this to work, GenTreeJitIntrinsic was updated to track the baseType as a CorInfoType rather than as a var_types (as discussed in #36160 (comment)). There is additionally a new JitType2PreciseVarType method which ensures that a CorInfoType is converted to a var_types in a way that preserves the sign (JITtype2varType will convert CORINFO_TYPE_UINT to CORINFO_TYPE_INT otherwise).
I ran jit-diff --pmi for --frameworks, --benchmarks, and --tests after the second commit to ensure there were no diffs due to the above changes. I then added the three latter commits supporting Vector<nint> and Vector<nuint>.
Edit: The vast majority of the PR is hardware intrinsic tests being added via the NotSupported template (so they are auto-generated, like most of the hwintrinsic tests).

Review of the PR can be simplified by just reviewing one of the generated tests since they all follow the same pattern.
Edit: This work was completed:
I am marking this as a draft until I can get some more tests up, including negative validating for nint/nuint on Vector64/128/256<T>.
I will also take a look at updating the couple places where we still have using nuint_t = System.UInt64, such as in Utf16Utility.Validation.cs
@ghost
ghost
commented
Apr 7, 2021

Copy link


Copy Markdown

Note regarding the new-api-needs-documentation label:
This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.
@ghostghost
added

area-CodeGen-coreclr
CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI
new-api-needs-documentation

labels
Apr 7, 2021
@tannergooding
tannergoodingforce-pushed
the
intrinsic-type
branch
3 times, most recently
from
b686f43 to
f3be3d6CompareApril 7, 2021 22:12
@tannergooding
tannergoodingforce-pushed
the
intrinsic-type
branch
2 times, most recently
from
3053f08 to
755f6e0CompareApril 8, 2021 02:30
@tannergooding
tannergooding
commented
Apr 8, 2021•

edited

Loading

Copy link


Copy Markdown

MemberAuthor
@fanyang-mono, could you assist with the mono failures here?
It looks like there are two kinds of failures:
  1. Mono isn't correctly treating Vector128<nint>.Zero as unsupported
  2. Mono is faulting in src/mono/mono/mini/simd-intrinsics.c due to an assertion that shouldn't be reached (looks like its not handling the MONO_TYPE_ for nint and nuint).
Related, it looks like Mono has some hard-coded logic around ThrowForUnsupportedVectorBaseType (in src/mono/mono/mini/intrinsics.c) and that is being renamed/split into two methods for this PR.
The latter two issues look fairly straightforward to resolve, I'm just not familiar with what the correct MONO_TYPE_ is for nint or nuint.

The first issue I'm not sure where to start looking.
@fanyang-mono
fanyang-mono
commented
Apr 8, 2021

Copy link


Copy Markdown

Member
@fanyang-mono, could you assist with the mono failures here?
It looks like there are two kinds of failures:
  1. Mono isn't correctly treating Vector128<nint>.Zero as unsupported
  2. Mono is faulting in src/mono/mono/mini/simd-intrinsics.c due to an assertion that shouldn't be reached (looks like its not handling the MONO_TYPE_ for nint and nuint).
Related, it looks like Mono has some hard-coded logic around ThrowForUnsupportedVectorBaseType (in src/mono/mono/mini/intrinsics.c) and that is being renamed/split into two methods for this PR.
The latter two issues look fairly straightforward to resolve, I'm just not familiar with what the correct MONO_TYPE_ is for nint or nuint.

The first issue I'm not sure where to start looking.
nint and nuint is currently not support by mono. @vargaz Zoltan, could you please provide a little more details, if there is any?
@tannergooding
tannergooding
commented
Apr 8, 2021

Copy link


Copy Markdown

MemberAuthor
nint and nuint is currently not support by mono
I'm not sure I understand this, they are just aliases for System.IntPtr and System.UIntPtr as far as the JIT type system is concerned?
@vargaz
vargaz
commented
Apr 8, 2021

Copy link


Copy Markdown

Contributor
IntPtr/UIntPtr is MONO_TYPE_I/MONO_TYPE_U.
@fanyang-mono
fanyang-mono
commented
Apr 8, 2021

Copy link


Copy Markdown

Member
nint and nuint is currently not support by mono
I'm not sure I understand this, they are just aliases for System.IntPtr and System.UIntPtr as far as the JIT type system is concerned?
If that's the case, they should be mapped to MONO_TYPE_I and MONO_TYPE_U. Sorry that I misunderstood them with struct types.
@tannergooding
tannergooding
commented
Apr 8, 2021•

edited

Loading

Copy link


Copy Markdown

MemberAuthor
I believe I've fixed the first issue (70432e5):
Mono isn't correctly treating Vector128.Zero as unsupported
and the third issue (c3107e0):
it looks like Mono has some hard-coded logic around ThrowForUnsupportedVectorBaseType (in src/mono/mono/mini/intrinsics.c) and that is being renamed/split into two methods for this PR.
I've also fixed part of the second issue (also c3107e0):
Mono is faulting in src/mono/mono/mini/simd-intrinsics.c due to an assertion that shouldn't be reached (looks like its not handling the MONO_TYPE_ for nint and nuint).
The remainder of the second issue looks to be that a couple code paths will still assert (type_to_expand_op, type_to_insert_op, and type_to_extract_var_op) since MONO_TYPE_I8 and MONO_TYPE_U8 aren't handled.

It isn't clear if this is better handled by picking an existing op (e.g. OP_EXPAND_I4 when targeting 32-bit and OP_EXPAND_I8 when targeting 64-bit) or if it is better to add a new op (e.g. OP_EXPAND_I) and plumb the handling through.
@fanyang-mono
fanyang-mono
commented
Apr 8, 2021

Copy link


Copy Markdown

Member
I believe I've fixed the first issue (70432e5):
Mono isn't correctly treating Vector128.Zero as unsupported
and the third issue (c3107e0):
it looks like Mono has some hard-coded logic around ThrowForUnsupportedVectorBaseType (in src/mono/mono/mini/intrinsics.c) and that is being renamed/split into two methods for this PR.
I've also fixed part of the second issue (also c3107e0):
Mono is faulting in src/mono/mono/mini/simd-intrinsics.c due to an assertion that shouldn't be reached (looks like its not handling the MONO_TYPE_ for nint and nuint).
The remainder of the second issue looks to be that a couple code paths will still assert (type_to_expand_op, type_to_insert_op, and type_to_extract_var_op) since MONO_TYPE_I8 and MONO_TYPE_U8 aren't handled.

It isn't clear if this is better handled by picking an existing op (e.g. OP_EXPAND_I4 when targeting 32-bit and OP_EXPAND_I8 when targeting 64-bit) or if it is better to add a new op (e.g. OP_EXPAND_I) and plumb the handling through.
Maybe something like this
case MONO_TYPE_I:
#if TARGET_SIZEOF_VOID_P == 8
<treat it the same as I8>
#else
<treat it as I4>
#endif

@tannergooding
tannergooding
commented
Apr 8, 2021•

edited

Loading

Copy link


Copy Markdown

MemberAuthor
I believe the relevant mono paths are now updated to correctly handle Vector<nint> and Vector<nuint> and to block the same for Vector64/128/256<T> (at least until we take those to API review and hopefully unblock them as well). Hopefully CI passes now, thanks for the help! 😄
@tannergooding
tannergooding
marked this pull request as ready for review
April 8, 2021 21:44
@tannergooding
tannergooding
commented
Apr 8, 2021

Copy link


Copy Markdown

MemberAuthor
CC. @echesakovMSFT, @dotnet/jit-contrib for review
@JulieLeeMSFTJulieLeeMSFT
added this to the 6.0.0 milestone
Apr 8, 2021
@lambdageek
lambdageek
commented
Apr 8, 2021

Copy link


Copy Markdown

Member
@vargaz could you review the mono commit 8eb6fe9
@vargaz
vargaz
commented
Apr 9, 2021

Copy link


Copy Markdown

Contributor
The mono changes look ok to me.

This was referenced Apr 9, 2021

Closed


Closed

@tannergooding
Updating the Vector64/128/256<T> tests to have NotSupported validatio…
ed5db1f
…n for nint/nuint
@tannergooding
Splitting ThrowHelper.ThrowForUnsupportedVectorBaseType into separate…
35764d7
… functions for Numerics vs Intrinsics
@tannergooding
Updating Utf16Utility.Validation to directly use Vector<nuint>
57fc73d
@tannergooding
Don't use the auxiliary type to hold a SIMD type, since it can be tri…
3d4fe63
…vially pulled from the operand instead
@tannergooding
Split the mono handling for ThrowForUnsupportedVectorBaseType into Th…
fa2d443
…rowForUnsupportedNumericsVectorBaseType and ThrowForUnsupportedIntrinsicsVectorBaseType
@tannergooding
Add basic handling for MONO_TYPE_I and MONO_TYPE_U to simd-intrinsics.c
18c2c1a
@tannergooding
Ensure simd-intrinsics.c in Mono handles MONO_TYPE_I and `MONO_TYPE…
b311562
…_U` on relevant code paths
@tannergooding
Ensure we don't assert when encountering synthesized Vector128<nint> …
c150826
…handles
@tannergooding
tannergooding
commented
Apr 14, 2021

Copy link


Copy Markdown

MemberAuthor
Rebased to resolve a conflict, believe I've also resolved the remaining ARM64 issue (it passed on my Windows box).
@tannergooding
tannergooding
commented
Apr 15, 2021

Copy link


Copy Markdown

MemberAuthor
The mono changes look ok to me.
@vargaz, I had to push another commit for Mono: 0f4764d
A bit of the handling existed in mini-amd64.c and so was missed in my first pass, but caught by the tests.

I think I've gotten it all this time, but we'll see what CI says 😄
@tannergooding
tannergooding
commented
Apr 15, 2021

Copy link


Copy Markdown

MemberAuthor
Everything is passing now except for two LLVM AOT scenarios. It isn't clear to me what's wrong here given that the regular Mono leg passed.
@vargaz or @fanyang-mono, could you provide some guidance on how to root cause the failure here?
@tannergooding
tannergooding
commented
Apr 15, 2021

Copy link


Copy Markdown

MemberAuthor
Actually, I may have found it, there is a single line calling out an assert about halfway through the log:
  • Assertion: should not be reached at /__w/1/s/src/mono/mono/mini/mini-llvm.c:580
@tannergooding
tannergooding
commented
Apr 16, 2021

Copy link


Copy Markdown

MemberAuthor
Only test failures are unrelated and due to #51346
This should be ready for final review/merge.
@GrabYourPitchforks
GrabYourPitchforks
commented
Apr 17, 2021

Copy link


Copy Markdown

Member
My small contribution to the review: commit 57fc73d LGTM!
echesakov
echesakov
approved these changes
Apr 20, 2021
View reviewed changes
@echesakovechesakov
left a comment


Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Thank you for your contribution, @tannergooding!
cc @dotnet/jit-contrib
@tannergooding
tannergooding
merged commit 17506ca
into
dotnet:mainApr 20, 2021

This was referenced Apr 21, 2021

Closed

 Merged

@JulieLeeMSFTJulieLeeMSFT
mentioned this pull request
Apr 27, 2021

Closed

@AntonLapounovAntonLapounov
mentioned this pull request
Apr 28, 2021
 Closed

@ghostghost
locked as resolved and limited conversation to collaborators
May 20, 2021
@tannergooding
tannergooding
deleted the

intrinsic-type

branch
July 1, 2025 14:39
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers

@CoffeeFluxCoffeeFluxAwaiting requested review from CoffeeFlux
@lambdageeklambdageekAwaiting requested review from lambdageek
@SamMonoRTSamMonoRTAwaiting requested review from SamMonoRT
@vargazvargazAwaiting requested review from vargaz
@EgorBoEgorBoAwaiting requested review from EgorBo
@imhameedimhameedAwaiting requested review from imhameed

1 more reviewer

@echesakovechesakovechesakov approved these changes
Reviewers whose approvals may not affect merge requirements

Assignees

@tannergoodingtannergooding

Labels

area-CodeGen-coreclrCLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI

Projects


None yet


Milestone

6.0.0

Development

Successfully merging this pull request may close these issues.

Consider expanding Vector<T> to support nint and nuint

7 participants

@tannergooding@fanyang-mono@vargaz@lambdageek@GrabYourPitchforks@echesakov@JulieLeeMSFT

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Auto-enable theater mode on YouTube\n(function() {\n function tryTheater() {\n var btn = document.querySelector('button[aria-label=\"Theater mode\"], ytd-player #player button[title=\"Theater mode\"]');\n if (btn && !btn.classList.contains('activated')) {\n btn.click();\n }\n }\n \n // Try immediately\n tryTheater();\n \n // Try after navigation (SPA)\n var lastUrl = location.href;\n setInterval(function() {\n if (location.href !== lastUrl) {\n lastUrl = location.href;\n setTimeout(tryTheater, 500);\n }\n }, 1000);\n \n // Also try on player load\n var observer = new MutationObserver(tryTheater);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "YouTube Theater Mode Default");
}
} catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
Updating Vector<T> to support nint and nuint - #50832
Merged
tannergooding merged 19 commits into
dotnet:mainfrom 
tannergooding:intrinsic-type
Apr 20, 2021
Merged
Updating Vector<T> to support nint and nuint#50832
tannergooding merged 19 commits into
dotnet:mainfrom 
tannergooding:intrinsic-type
Conversation
@tannergooding
@tannergoodingtannergooding
commented
Apr 7, 2021•

edited

Loading

Copy link


Copy Markdown

Member
This resolves#36160
In order for this to work, GenTreeJitIntrinsic was updated to track the baseType as a CorInfoType rather than as a var_types (as discussed in #36160 (comment)). There is additionally a new JitType2PreciseVarType method which ensures that a CorInfoType is converted to a var_types in a way that preserves the sign (JITtype2varType will convert CORINFO_TYPE_UINT to CORINFO_TYPE_INT otherwise).
I ran jit-diff --pmi for --frameworks, --benchmarks, and --tests after the second commit to ensure there were no diffs due to the above changes. I then added the three latter commits supporting Vector<nint> and Vector<nuint>.
Edit: The vast majority of the PR is hardware intrinsic tests being added via the NotSupported template (so they are auto-generated, like most of the hwintrinsic tests).

Review of the PR can be simplified by just reviewing one of the generated tests since they all follow the same pattern.
Edit: This work was completed:
I am marking this as a draft until I can get some more tests up, including negative validating for nint/nuint on Vector64/128/256<T>.
I will also take a look at updating the couple places where we still have using nuint_t = System.UInt64, such as in Utf16Utility.Validation.cs
@ghost
ghost
commented
Apr 7, 2021

Copy link


Copy Markdown

Note regarding the new-api-needs-documentation label:
This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.
@ghostghost
added

area-CodeGen-coreclr
CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI
new-api-needs-documentation

labels
Apr 7, 2021
@tannergooding
tannergoodingforce-pushed
the
intrinsic-type
branch
3 times, most recently
from
b686f43 to
f3be3d6CompareApril 7, 2021 22:12
@tannergooding
tannergoodingforce-pushed
the
intrinsic-type
branch
2 times, most recently
from
3053f08 to
755f6e0CompareApril 8, 2021 02:30
@tannergooding
tannergooding
commented
Apr 8, 2021•

edited

Loading

Copy link


Copy Markdown

MemberAuthor
@fanyang-mono, could you assist with the mono failures here?
It looks like there are two kinds of failures:
  1. Mono isn't correctly treating Vector128<nint>.Zero as unsupported
  2. Mono is faulting in src/mono/mono/mini/simd-intrinsics.c due to an assertion that shouldn't be reached (looks like its not handling the MONO_TYPE_ for nint and nuint).
Related, it looks like Mono has some hard-coded logic around ThrowForUnsupportedVectorBaseType (in src/mono/mono/mini/intrinsics.c) and that is being renamed/split into two methods for this PR.
The latter two issues look fairly straightforward to resolve, I'm just not familiar with what the correct MONO_TYPE_ is for nint or nuint.

The first issue I'm not sure where to start looking.
@fanyang-mono
fanyang-mono
commented
Apr 8, 2021

Copy link


Copy Markdown

Member
@fanyang-mono, could you assist with the mono failures here?
It looks like there are two kinds of failures:
  1. Mono isn't correctly treating Vector128<nint>.Zero as unsupported
  2. Mono is faulting in src/mono/mono/mini/simd-intrinsics.c due to an assertion that shouldn't be reached (looks like its not handling the MONO_TYPE_ for nint and nuint).
Related, it looks like Mono has some hard-coded logic around ThrowForUnsupportedVectorBaseType (in src/mono/mono/mini/intrinsics.c) and that is being renamed/split into two methods for this PR.
The latter two issues look fairly straightforward to resolve, I'm just not familiar with what the correct MONO_TYPE_ is for nint or nuint.

The first issue I'm not sure where to start looking.
nint and nuint is currently not support by mono. @vargaz Zoltan, could you please provide a little more details, if there is any?
@tannergooding
tannergooding
commented
Apr 8, 2021

Copy link


Copy Markdown

MemberAuthor
nint and nuint is currently not support by mono
I'm not sure I understand this, they are just aliases for System.IntPtr and System.UIntPtr as far as the JIT type system is concerned?
@vargaz
vargaz
commented
Apr 8, 2021

Copy link


Copy Markdown

Contributor
IntPtr/UIntPtr is MONO_TYPE_I/MONO_TYPE_U.
@fanyang-mono
fanyang-mono
commented
Apr 8, 2021

Copy link


Copy Markdown

Member
nint and nuint is currently not support by mono
I'm not sure I understand this, they are just aliases for System.IntPtr and System.UIntPtr as far as the JIT type system is concerned?
If that's the case, they should be mapped to MONO_TYPE_I and MONO_TYPE_U. Sorry that I misunderstood them with struct types.
@tannergooding
tannergooding
commented
Apr 8, 2021•

edited

Loading

Copy link


Copy Markdown

MemberAuthor
I believe I've fixed the first issue (70432e5):
Mono isn't correctly treating Vector128.Zero as unsupported
and the third issue (c3107e0):
it looks like Mono has some hard-coded logic around ThrowForUnsupportedVectorBaseType (in src/mono/mono/mini/intrinsics.c) and that is being renamed/split into two methods for this PR.
I've also fixed part of the second issue (also c3107e0):
Mono is faulting in src/mono/mono/mini/simd-intrinsics.c due to an assertion that shouldn't be reached (looks like its not handling the MONO_TYPE_ for nint and nuint).
The remainder of the second issue looks to be that a couple code paths will still assert (type_to_expand_op, type_to_insert_op, and type_to_extract_var_op) since MONO_TYPE_I8 and MONO_TYPE_U8 aren't handled.

It isn't clear if this is better handled by picking an existing op (e.g. OP_EXPAND_I4 when targeting 32-bit and OP_EXPAND_I8 when targeting 64-bit) or if it is better to add a new op (e.g. OP_EXPAND_I) and plumb the handling through.
@fanyang-mono
fanyang-mono
commented
Apr 8, 2021

Copy link


Copy Markdown

Member
I believe I've fixed the first issue (70432e5):
Mono isn't correctly treating Vector128.Zero as unsupported
and the third issue (c3107e0):
it looks like Mono has some hard-coded logic around ThrowForUnsupportedVectorBaseType (in src/mono/mono/mini/intrinsics.c) and that is being renamed/split into two methods for this PR.
I've also fixed part of the second issue (also c3107e0):
Mono is faulting in src/mono/mono/mini/simd-intrinsics.c due to an assertion that shouldn't be reached (looks like its not handling the MONO_TYPE_ for nint and nuint).
The remainder of the second issue looks to be that a couple code paths will still assert (type_to_expand_op, type_to_insert_op, and type_to_extract_var_op) since MONO_TYPE_I8 and MONO_TYPE_U8 aren't handled.

It isn't clear if this is better handled by picking an existing op (e.g. OP_EXPAND_I4 when targeting 32-bit and OP_EXPAND_I8 when targeting 64-bit) or if it is better to add a new op (e.g. OP_EXPAND_I) and plumb the handling through.
Maybe something like this
case MONO_TYPE_I:
#if TARGET_SIZEOF_VOID_P == 8
<treat it the same as I8>
#else
<treat it as I4>
#endif

@tannergooding
tannergooding
commented
Apr 8, 2021•

edited

Loading

Copy link


Copy Markdown

MemberAuthor
I believe the relevant mono paths are now updated to correctly handle Vector<nint> and Vector<nuint> and to block the same for Vector64/128/256<T> (at least until we take those to API review and hopefully unblock them as well). Hopefully CI passes now, thanks for the help! 😄
@tannergooding
tannergooding
marked this pull request as ready for review
April 8, 2021 21:44
@tannergooding
tannergooding
commented
Apr 8, 2021

Copy link


Copy Markdown

MemberAuthor
CC. @echesakovMSFT, @dotnet/jit-contrib for review
@JulieLeeMSFTJulieLeeMSFT
added this to the 6.0.0 milestone
Apr 8, 2021
@lambdageek
lambdageek
commented
Apr 8, 2021

Copy link


Copy Markdown

Member
@vargaz could you review the mono commit 8eb6fe9
@vargaz
vargaz
commented
Apr 9, 2021

Copy link


Copy Markdown

Contributor
The mono changes look ok to me.

This was referenced Apr 9, 2021

Closed


Closed

@tannergooding
Updating the Vector64/128/256<T> tests to have NotSupported validatio…
ed5db1f
…n for nint/nuint
@tannergooding
Splitting ThrowHelper.ThrowForUnsupportedVectorBaseType into separate…
35764d7
… functions for Numerics vs Intrinsics
@tannergooding
Updating Utf16Utility.Validation to directly use Vector<nuint>
57fc73d
@tannergooding
Don't use the auxiliary type to hold a SIMD type, since it can be tri…
3d4fe63
…vially pulled from the operand instead
@tannergooding
Split the mono handling for ThrowForUnsupportedVectorBaseType into Th…
fa2d443
…rowForUnsupportedNumericsVectorBaseType and ThrowForUnsupportedIntrinsicsVectorBaseType
@tannergooding
Add basic handling for MONO_TYPE_I and MONO_TYPE_U to simd-intrinsics.c
18c2c1a
@tannergooding
Ensure simd-intrinsics.c in Mono handles MONO_TYPE_I and `MONO_TYPE…
b311562
…_U` on relevant code paths
@tannergooding
Ensure we don't assert when encountering synthesized Vector128<nint> …
c150826
…handles
@tannergooding
tannergooding
commented
Apr 14, 2021

Copy link


Copy Markdown

MemberAuthor
Rebased to resolve a conflict, believe I've also resolved the remaining ARM64 issue (it passed on my Windows box).
@tannergooding
tannergooding
commented
Apr 15, 2021

Copy link


Copy Markdown

MemberAuthor
The mono changes look ok to me.
@vargaz, I had to push another commit for Mono: 0f4764d
A bit of the handling existed in mini-amd64.c and so was missed in my first pass, but caught by the tests.

I think I've gotten it all this time, but we'll see what CI says 😄
@tannergooding
tannergooding
commented
Apr 15, 2021

Copy link


Copy Markdown

MemberAuthor
Everything is passing now except for two LLVM AOT scenarios. It isn't clear to me what's wrong here given that the regular Mono leg passed.
@vargaz or @fanyang-mono, could you provide some guidance on how to root cause the failure here?
@tannergooding
tannergooding
commented
Apr 15, 2021

Copy link


Copy Markdown

MemberAuthor
Actually, I may have found it, there is a single line calling out an assert about halfway through the log:
  • Assertion: should not be reached at /__w/1/s/src/mono/mono/mini/mini-llvm.c:580
@tannergooding
tannergooding
commented
Apr 16, 2021

Copy link


Copy Markdown

MemberAuthor
Only test failures are unrelated and due to #51346
This should be ready for final review/merge.
@GrabYourPitchforks
GrabYourPitchforks
commented
Apr 17, 2021

Copy link


Copy Markdown

Member
My small contribution to the review: commit 57fc73d LGTM!
echesakov
echesakov
approved these changes
Apr 20, 2021
View reviewed changes
@echesakovechesakov
left a comment


Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Thank you for your contribution, @tannergooding!
cc @dotnet/jit-contrib
@tannergooding
tannergooding
merged commit 17506ca
into
dotnet:mainApr 20, 2021

This was referenced Apr 21, 2021

Closed

 Merged

@JulieLeeMSFTJulieLeeMSFT
mentioned this pull request
Apr 27, 2021

Closed

@AntonLapounovAntonLapounov
mentioned this pull request
Apr 28, 2021
 Closed

@ghostghost
locked as resolved and limited conversation to collaborators
May 20, 2021
@tannergooding
tannergooding
deleted the

intrinsic-type

branch
July 1, 2025 14:39
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers

@CoffeeFluxCoffeeFluxAwaiting requested review from CoffeeFlux
@lambdageeklambdageekAwaiting requested review from lambdageek
@SamMonoRTSamMonoRTAwaiting requested review from SamMonoRT
@vargazvargazAwaiting requested review from vargaz
@EgorBoEgorBoAwaiting requested review from EgorBo
@imhameedimhameedAwaiting requested review from imhameed

1 more reviewer

@echesakovechesakovechesakov approved these changes
Reviewers whose approvals may not affect merge requirements

Assignees

@tannergoodingtannergooding

Labels

area-CodeGen-coreclrCLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI

Projects


None yet


Milestone

6.0.0

Development

Successfully merging this pull request may close these issues.

Consider expanding Vector<T> to support nint and nuint

7 participants

@tannergooding@fanyang-mono@vargaz@lambdageek@GrabYourPitchforks@echesakov@JulieLeeMSFT

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Remove or un-stick sticky/fixed headers that block content\n(function() {\n function unstick() {\n document.querySelectorAll('header, nav, [role=\"banner\"], .header, .navbar, .sticky, .fixed-top, [style*=\"position: fixed\"], [style*=\"position:sticky\"]').forEach(function(el) {\n if (el.style.position === 'fixed' || el.style.position === 'sticky' || \n getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {\n el.style.position = 'static';\n el.style.top = 'auto';\n el.style.zIndex = 'auto';\n }\n });\n }\n \n unstick();\n \n var observer = new MutationObserver(unstick);\n observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });\n})();", "Kill Sticky Headers");
}
} catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
Updating Vector<T> to support nint and nuint - #50832
Merged
tannergooding merged 19 commits into
dotnet:mainfrom 
tannergooding:intrinsic-type
Apr 20, 2021
Merged
Updating Vector<T> to support nint and nuint#50832
tannergooding merged 19 commits into
dotnet:mainfrom 
tannergooding:intrinsic-type
Conversation
@tannergooding
@tannergoodingtannergooding
commented
Apr 7, 2021•

edited

Loading

Copy link


Copy Markdown

Member
This resolves#36160
In order for this to work, GenTreeJitIntrinsic was updated to track the baseType as a CorInfoType rather than as a var_types (as discussed in #36160 (comment)). There is additionally a new JitType2PreciseVarType method which ensures that a CorInfoType is converted to a var_types in a way that preserves the sign (JITtype2varType will convert CORINFO_TYPE_UINT to CORINFO_TYPE_INT otherwise).
I ran jit-diff --pmi for --frameworks, --benchmarks, and --tests after the second commit to ensure there were no diffs due to the above changes. I then added the three latter commits supporting Vector<nint> and Vector<nuint>.
Edit: The vast majority of the PR is hardware intrinsic tests being added via the NotSupported template (so they are auto-generated, like most of the hwintrinsic tests).

Review of the PR can be simplified by just reviewing one of the generated tests since they all follow the same pattern.
Edit: This work was completed:
I am marking this as a draft until I can get some more tests up, including negative validating for nint/nuint on Vector64/128/256<T>.
I will also take a look at updating the couple places where we still have using nuint_t = System.UInt64, such as in Utf16Utility.Validation.cs
@ghost
ghost
commented
Apr 7, 2021

Copy link


Copy Markdown

Note regarding the new-api-needs-documentation label:
This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.
@ghostghost
added

area-CodeGen-coreclr
CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI
new-api-needs-documentation

labels
Apr 7, 2021
@tannergooding
tannergoodingforce-pushed
the
intrinsic-type
branch
3 times, most recently
from
b686f43 to
f3be3d6CompareApril 7, 2021 22:12
@tannergooding
tannergoodingforce-pushed
the
intrinsic-type
branch
2 times, most recently
from
3053f08 to
755f6e0CompareApril 8, 2021 02:30
@tannergooding
tannergooding
commented
Apr 8, 2021•

edited

Loading

Copy link


Copy Markdown

MemberAuthor
@fanyang-mono, could you assist with the mono failures here?
It looks like there are two kinds of failures:
  1. Mono isn't correctly treating Vector128<nint>.Zero as unsupported
  2. Mono is faulting in src/mono/mono/mini/simd-intrinsics.c due to an assertion that shouldn't be reached (looks like its not handling the MONO_TYPE_ for nint and nuint).
Related, it looks like Mono has some hard-coded logic around ThrowForUnsupportedVectorBaseType (in src/mono/mono/mini/intrinsics.c) and that is being renamed/split into two methods for this PR.
The latter two issues look fairly straightforward to resolve, I'm just not familiar with what the correct MONO_TYPE_ is for nint or nuint.

The first issue I'm not sure where to start looking.
@fanyang-mono
fanyang-mono
commented
Apr 8, 2021

Copy link


Copy Markdown

Member
@fanyang-mono, could you assist with the mono failures here?
It looks like there are two kinds of failures:
  1. Mono isn't correctly treating Vector128<nint>.Zero as unsupported
  2. Mono is faulting in src/mono/mono/mini/simd-intrinsics.c due to an assertion that shouldn't be reached (looks like its not handling the MONO_TYPE_ for nint and nuint).
Related, it looks like Mono has some hard-coded logic around ThrowForUnsupportedVectorBaseType (in src/mono/mono/mini/intrinsics.c) and that is being renamed/split into two methods for this PR.
The latter two issues look fairly straightforward to resolve, I'm just not familiar with what the correct MONO_TYPE_ is for nint or nuint.

The first issue I'm not sure where to start looking.
nint and nuint is currently not support by mono. @vargaz Zoltan, could you please provide a little more details, if there is any?
@tannergooding
tannergooding
commented
Apr 8, 2021

Copy link


Copy Markdown

MemberAuthor
nint and nuint is currently not support by mono
I'm not sure I understand this, they are just aliases for System.IntPtr and System.UIntPtr as far as the JIT type system is concerned?
@vargaz
vargaz
commented
Apr 8, 2021

Copy link


Copy Markdown

Contributor
IntPtr/UIntPtr is MONO_TYPE_I/MONO_TYPE_U.
@fanyang-mono
fanyang-mono
commented
Apr 8, 2021

Copy link


Copy Markdown

Member
nint and nuint is currently not support by mono
I'm not sure I understand this, they are just aliases for System.IntPtr and System.UIntPtr as far as the JIT type system is concerned?
If that's the case, they should be mapped to MONO_TYPE_I and MONO_TYPE_U. Sorry that I misunderstood them with struct types.
@tannergooding
tannergooding
commented
Apr 8, 2021•

edited

Loading

Copy link


Copy Markdown

MemberAuthor
I believe I've fixed the first issue (70432e5):
Mono isn't correctly treating Vector128.Zero as unsupported
and the third issue (c3107e0):
it looks like Mono has some hard-coded logic around ThrowForUnsupportedVectorBaseType (in src/mono/mono/mini/intrinsics.c) and that is being renamed/split into two methods for this PR.
I've also fixed part of the second issue (also c3107e0):
Mono is faulting in src/mono/mono/mini/simd-intrinsics.c due to an assertion that shouldn't be reached (looks like its not handling the MONO_TYPE_ for nint and nuint).
The remainder of the second issue looks to be that a couple code paths will still assert (type_to_expand_op, type_to_insert_op, and type_to_extract_var_op) since MONO_TYPE_I8 and MONO_TYPE_U8 aren't handled.

It isn't clear if this is better handled by picking an existing op (e.g. OP_EXPAND_I4 when targeting 32-bit and OP_EXPAND_I8 when targeting 64-bit) or if it is better to add a new op (e.g. OP_EXPAND_I) and plumb the handling through.
@fanyang-mono
fanyang-mono
commented
Apr 8, 2021

Copy link


Copy Markdown

Member
I believe I've fixed the first issue (70432e5):
Mono isn't correctly treating Vector128.Zero as unsupported
and the third issue (c3107e0):
it looks like Mono has some hard-coded logic around ThrowForUnsupportedVectorBaseType (in src/mono/mono/mini/intrinsics.c) and that is being renamed/split into two methods for this PR.
I've also fixed part of the second issue (also c3107e0):
Mono is faulting in src/mono/mono/mini/simd-intrinsics.c due to an assertion that shouldn't be reached (looks like its not handling the MONO_TYPE_ for nint and nuint).
The remainder of the second issue looks to be that a couple code paths will still assert (type_to_expand_op, type_to_insert_op, and type_to_extract_var_op) since MONO_TYPE_I8 and MONO_TYPE_U8 aren't handled.

It isn't clear if this is better handled by picking an existing op (e.g. OP_EXPAND_I4 when targeting 32-bit and OP_EXPAND_I8 when targeting 64-bit) or if it is better to add a new op (e.g. OP_EXPAND_I) and plumb the handling through.
Maybe something like this
case MONO_TYPE_I:
#if TARGET_SIZEOF_VOID_P == 8
<treat it the same as I8>
#else
<treat it as I4>
#endif

@tannergooding
tannergooding
commented
Apr 8, 2021•

edited

Loading

Copy link


Copy Markdown

MemberAuthor
I believe the relevant mono paths are now updated to correctly handle Vector<nint> and Vector<nuint> and to block the same for Vector64/128/256<T> (at least until we take those to API review and hopefully unblock them as well). Hopefully CI passes now, thanks for the help! 😄
@tannergooding
tannergooding
marked this pull request as ready for review
April 8, 2021 21:44
@tannergooding
tannergooding
commented
Apr 8, 2021

Copy link


Copy Markdown

MemberAuthor
CC. @echesakovMSFT, @dotnet/jit-contrib for review
@JulieLeeMSFTJulieLeeMSFT
added this to the 6.0.0 milestone
Apr 8, 2021
@lambdageek
lambdageek
commented
Apr 8, 2021

Copy link


Copy Markdown

Member
@vargaz could you review the mono commit 8eb6fe9
@vargaz
vargaz
commented
Apr 9, 2021

Copy link


Copy Markdown

Contributor
The mono changes look ok to me.

This was referenced Apr 9, 2021

Closed


Closed

@tannergooding
Updating the Vector64/128/256<T> tests to have NotSupported validatio…
ed5db1f
…n for nint/nuint
@tannergooding
Splitting ThrowHelper.ThrowForUnsupportedVectorBaseType into separate…
35764d7
… functions for Numerics vs Intrinsics
@tannergooding
Updating Utf16Utility.Validation to directly use Vector<nuint>
57fc73d
@tannergooding
Don't use the auxiliary type to hold a SIMD type, since it can be tri…
3d4fe63
…vially pulled from the operand instead
@tannergooding
Split the mono handling for ThrowForUnsupportedVectorBaseType into Th…
fa2d443
…rowForUnsupportedNumericsVectorBaseType and ThrowForUnsupportedIntrinsicsVectorBaseType
@tannergooding
Add basic handling for MONO_TYPE_I and MONO_TYPE_U to simd-intrinsics.c
18c2c1a
@tannergooding
Ensure simd-intrinsics.c in Mono handles MONO_TYPE_I and `MONO_TYPE…
b311562
…_U` on relevant code paths
@tannergooding
Ensure we don't assert when encountering synthesized Vector128<nint> …
c150826
…handles
@tannergooding
tannergooding
commented
Apr 14, 2021

Copy link


Copy Markdown

MemberAuthor
Rebased to resolve a conflict, believe I've also resolved the remaining ARM64 issue (it passed on my Windows box).
@tannergooding
tannergooding
commented
Apr 15, 2021

Copy link


Copy Markdown

MemberAuthor
The mono changes look ok to me.
@vargaz, I had to push another commit for Mono: 0f4764d
A bit of the handling existed in mini-amd64.c and so was missed in my first pass, but caught by the tests.

I think I've gotten it all this time, but we'll see what CI says 😄
@tannergooding
tannergooding
commented
Apr 15, 2021

Copy link


Copy Markdown

MemberAuthor
Everything is passing now except for two LLVM AOT scenarios. It isn't clear to me what's wrong here given that the regular Mono leg passed.
@vargaz or @fanyang-mono, could you provide some guidance on how to root cause the failure here?
@tannergooding
tannergooding
commented
Apr 15, 2021

Copy link


Copy Markdown

MemberAuthor
Actually, I may have found it, there is a single line calling out an assert about halfway through the log:
  • Assertion: should not be reached at /__w/1/s/src/mono/mono/mini/mini-llvm.c:580
@tannergooding
tannergooding
commented
Apr 16, 2021

Copy link


Copy Markdown

MemberAuthor
Only test failures are unrelated and due to #51346
This should be ready for final review/merge.
@GrabYourPitchforks
GrabYourPitchforks
commented
Apr 17, 2021

Copy link


Copy Markdown

Member
My small contribution to the review: commit 57fc73d LGTM!
echesakov
echesakov
approved these changes
Apr 20, 2021
View reviewed changes
@echesakovechesakov
left a comment


Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Thank you for your contribution, @tannergooding!
cc @dotnet/jit-contrib
@tannergooding
tannergooding
merged commit 17506ca
into
dotnet:mainApr 20, 2021

This was referenced Apr 21, 2021

Closed

 Merged

@JulieLeeMSFTJulieLeeMSFT
mentioned this pull request
Apr 27, 2021

Closed

@AntonLapounovAntonLapounov
mentioned this pull request
Apr 28, 2021
 Closed

@ghostghost
locked as resolved and limited conversation to collaborators
May 20, 2021
@tannergooding
tannergooding
deleted the

intrinsic-type

branch
July 1, 2025 14:39
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers

@CoffeeFluxCoffeeFluxAwaiting requested review from CoffeeFlux
@lambdageeklambdageekAwaiting requested review from lambdageek
@SamMonoRTSamMonoRTAwaiting requested review from SamMonoRT
@vargazvargazAwaiting requested review from vargaz
@EgorBoEgorBoAwaiting requested review from EgorBo
@imhameedimhameedAwaiting requested review from imhameed

1 more reviewer

@echesakovechesakovechesakov approved these changes
Reviewers whose approvals may not affect merge requirements

Assignees

@tannergoodingtannergooding

Labels

area-CodeGen-coreclrCLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI

Projects


None yet


Milestone

6.0.0

Development

Successfully merging this pull request may close these issues.

Consider expanding Vector<T> to support nint and nuint

7 participants

@tannergooding@fanyang-mono@vargaz@lambdageek@GrabYourPitchforks@echesakov@JulieLeeMSFT

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Universal Dark Mode - works on any site\n(function() {\n var enabled = true;\n \n function applyDarkMode() {\n if (!enabled) return;\n \n // Create style element if it doesn't exist\n var style = document.getElementById('universal-dark-mode-style');\n if (!style) {\n style = document.createElement('style');\n style.id = 'universal-dark-mode-style';\n document.head.appendChild(style);\n }\n \n // Dark mode CSS - inverts colors but preserves images/video\n style.textContent = '\n /* Invert everything except media */\n html {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #1a1a2e !important;\n }\n \n /* Restore images, videos, iframes, canvas */\n img, video, iframe, canvas, svg, picture, [style*=\"background-image\"] {\n filter: invert(1) hue-rotate(180deg) !important;\n }\n \n /* Preserve specific elements that should not be inverted */\n .no-dark-mode, .no-dark-mode *,\n [data-theme=\"light\"], [data-theme=\"light\"],\n .ace_editor, .ace_editor *,\n .CodeMirror, .CodeMirror *,\n .monaco-editor, .monaco-editor *,\n .markdown-body pre, .markdown-body pre *,\n .highlight, .highlight *,\n pre code, pre code * {\n filter: none !important;\n }\n \n /* Fix common UI elements */\n .modal, .popup, .dropdown-menu, .tooltip, .popover {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #2d2d44 !important;\n border-color: #444 !important;\n }\n \n /* Scrollbars */\n ::-webkit-scrollbar { background: #1a1a2e !important; }\n ::-webkit-scrollbar-thumb { background: #444 !important; }\n ::-webkit-scrollbar-thumb:hover { background: #555 !important; }\n \n /* Selection */\n ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ';\n }\n \n function removeDarkMode() {\n var style = document.getElementById('universal-dark-mode-style');\n if (style) style.remove();\n }\n \n // Toggle with Alt+Shift+D\n document.addEventListener('keydown', function(e) {\n if (e.altKey && e.shiftKey && e.key === 'D') {\n e.preventDefault();\n enabled = !enabled;\n if (enabled) {\n applyDarkMode();\n console.log('[Universal Dark Mode] Enabled');\n } else {\n removeDarkMode();\n console.log('[Universal Dark Mode] Disabled');\n }\n }\n });\n \n // Apply on load\n applyDarkMode();\n \n // Re-apply on dynamic content\n var observer = new MutationObserver(function(mutations) {\n if (enabled && !document.getElementById('universal-dark-mode-style')) {\n applyDarkMode();\n }\n });\n observer.observe(document.head, { childList: true });\n \n console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');\n})();", "Universal Dark Mode");
}
} catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); }
})();
})();

Skip to content
Updating Vector<T> to support nint and nuint - #50832
Merged
tannergooding merged 19 commits into
dotnet:mainfrom 
tannergooding:intrinsic-type
Apr 20, 2021
Merged
Updating Vector<T> to support nint and nuint#50832
tannergooding merged 19 commits into
dotnet:mainfrom 
tannergooding:intrinsic-type
Conversation
@tannergooding
@tannergoodingtannergooding
commented
Apr 7, 2021•

edited

Loading

Copy link


Copy Markdown

Member
This resolves#36160
In order for this to work, GenTreeJitIntrinsic was updated to track the baseType as a CorInfoType rather than as a var_types (as discussed in #36160 (comment)). There is additionally a new JitType2PreciseVarType method which ensures that a CorInfoType is converted to a var_types in a way that preserves the sign (JITtype2varType will convert CORINFO_TYPE_UINT to CORINFO_TYPE_INT otherwise).
I ran jit-diff --pmi for --frameworks, --benchmarks, and --tests after the second commit to ensure there were no diffs due to the above changes. I then added the three latter commits supporting Vector<nint> and Vector<nuint>.
Edit: The vast majority of the PR is hardware intrinsic tests being added via the NotSupported template (so they are auto-generated, like most of the hwintrinsic tests).

Review of the PR can be simplified by just reviewing one of the generated tests since they all follow the same pattern.
Edit: This work was completed:
I am marking this as a draft until I can get some more tests up, including negative validating for nint/nuint on Vector64/128/256<T>.
I will also take a look at updating the couple places where we still have using nuint_t = System.UInt64, such as in Utf16Utility.Validation.cs
@ghost
ghost
commented
Apr 7, 2021

Copy link


Copy Markdown

Note regarding the new-api-needs-documentation label:
This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.
@ghostghost
added

area-CodeGen-coreclr
CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI
new-api-needs-documentation

labels
Apr 7, 2021
@tannergooding
tannergoodingforce-pushed
the
intrinsic-type
branch
3 times, most recently
from
b686f43 to
f3be3d6CompareApril 7, 2021 22:12
@tannergooding
tannergoodingforce-pushed
the
intrinsic-type
branch
2 times, most recently
from
3053f08 to
755f6e0CompareApril 8, 2021 02:30
@tannergooding
tannergooding
commented
Apr 8, 2021•

edited

Loading

Copy link


Copy Markdown

MemberAuthor
@fanyang-mono, could you assist with the mono failures here?
It looks like there are two kinds of failures:
  1. Mono isn't correctly treating Vector128<nint>.Zero as unsupported
  2. Mono is faulting in src/mono/mono/mini/simd-intrinsics.c due to an assertion that shouldn't be reached (looks like its not handling the MONO_TYPE_ for nint and nuint).
Related, it looks like Mono has some hard-coded logic around ThrowForUnsupportedVectorBaseType (in src/mono/mono/mini/intrinsics.c) and that is being renamed/split into two methods for this PR.
The latter two issues look fairly straightforward to resolve, I'm just not familiar with what the correct MONO_TYPE_ is for nint or nuint.

The first issue I'm not sure where to start looking.
@fanyang-mono
fanyang-mono
commented
Apr 8, 2021

Copy link


Copy Markdown

Member
@fanyang-mono, could you assist with the mono failures here?
It looks like there are two kinds of failures:
  1. Mono isn't correctly treating Vector128<nint>.Zero as unsupported
  2. Mono is faulting in src/mono/mono/mini/simd-intrinsics.c due to an assertion that shouldn't be reached (looks like its not handling the MONO_TYPE_ for nint and nuint).
Related, it looks like Mono has some hard-coded logic around ThrowForUnsupportedVectorBaseType (in src/mono/mono/mini/intrinsics.c) and that is being renamed/split into two methods for this PR.
The latter two issues look fairly straightforward to resolve, I'm just not familiar with what the correct MONO_TYPE_ is for nint or nuint.

The first issue I'm not sure where to start looking.
nint and nuint is currently not support by mono. @vargaz Zoltan, could you please provide a little more details, if there is any?
@tannergooding
tannergooding
commented
Apr 8, 2021

Copy link


Copy Markdown

MemberAuthor
nint and nuint is currently not support by mono
I'm not sure I understand this, they are just aliases for System.IntPtr and System.UIntPtr as far as the JIT type system is concerned?
@vargaz
vargaz
commented
Apr 8, 2021

Copy link


Copy Markdown

Contributor
IntPtr/UIntPtr is MONO_TYPE_I/MONO_TYPE_U.
@fanyang-mono
fanyang-mono
commented
Apr 8, 2021

Copy link


Copy Markdown

Member
nint and nuint is currently not support by mono
I'm not sure I understand this, they are just aliases for System.IntPtr and System.UIntPtr as far as the JIT type system is concerned?
If that's the case, they should be mapped to MONO_TYPE_I and MONO_TYPE_U. Sorry that I misunderstood them with struct types.
@tannergooding
tannergooding
commented
Apr 8, 2021•

edited

Loading

Copy link


Copy Markdown

MemberAuthor
I believe I've fixed the first issue (70432e5):
Mono isn't correctly treating Vector128.Zero as unsupported
and the third issue (c3107e0):
it looks like Mono has some hard-coded logic around ThrowForUnsupportedVectorBaseType (in src/mono/mono/mini/intrinsics.c) and that is being renamed/split into two methods for this PR.
I've also fixed part of the second issue (also c3107e0):
Mono is faulting in src/mono/mono/mini/simd-intrinsics.c due to an assertion that shouldn't be reached (looks like its not handling the MONO_TYPE_ for nint and nuint).
The remainder of the second issue looks to be that a couple code paths will still assert (type_to_expand_op, type_to_insert_op, and type_to_extract_var_op) since MONO_TYPE_I8 and MONO_TYPE_U8 aren't handled.

It isn't clear if this is better handled by picking an existing op (e.g. OP_EXPAND_I4 when targeting 32-bit and OP_EXPAND_I8 when targeting 64-bit) or if it is better to add a new op (e.g. OP_EXPAND_I) and plumb the handling through.
@fanyang-mono
fanyang-mono
commented
Apr 8, 2021

Copy link


Copy Markdown

Member
I believe I've fixed the first issue (70432e5):
Mono isn't correctly treating Vector128.Zero as unsupported
and the third issue (c3107e0):
it looks like Mono has some hard-coded logic around ThrowForUnsupportedVectorBaseType (in src/mono/mono/mini/intrinsics.c) and that is being renamed/split into two methods for this PR.
I've also fixed part of the second issue (also c3107e0):
Mono is faulting in src/mono/mono/mini/simd-intrinsics.c due to an assertion that shouldn't be reached (looks like its not handling the MONO_TYPE_ for nint and nuint).
The remainder of the second issue looks to be that a couple code paths will still assert (type_to_expand_op, type_to_insert_op, and type_to_extract_var_op) since MONO_TYPE_I8 and MONO_TYPE_U8 aren't handled.

It isn't clear if this is better handled by picking an existing op (e.g. OP_EXPAND_I4 when targeting 32-bit and OP_EXPAND_I8 when targeting 64-bit) or if it is better to add a new op (e.g. OP_EXPAND_I) and plumb the handling through.
Maybe something like this
case MONO_TYPE_I:
#if TARGET_SIZEOF_VOID_P == 8
<treat it the same as I8>
#else
<treat it as I4>
#endif

@tannergooding
tannergooding
commented
Apr 8, 2021•

edited

Loading

Copy link


Copy Markdown

MemberAuthor
I believe the relevant mono paths are now updated to correctly handle Vector<nint> and Vector<nuint> and to block the same for Vector64/128/256<T> (at least until we take those to API review and hopefully unblock them as well). Hopefully CI passes now, thanks for the help! 😄
@tannergooding
tannergooding
marked this pull request as ready for review
April 8, 2021 21:44
@tannergooding
tannergooding
commented
Apr 8, 2021

Copy link


Copy Markdown

MemberAuthor
CC. @echesakovMSFT, @dotnet/jit-contrib for review
@JulieLeeMSFTJulieLeeMSFT
added this to the 6.0.0 milestone
Apr 8, 2021
@lambdageek
lambdageek
commented
Apr 8, 2021

Copy link


Copy Markdown

Member
@vargaz could you review the mono commit 8eb6fe9
@vargaz
vargaz
commented
Apr 9, 2021

Copy link


Copy Markdown

Contributor
The mono changes look ok to me.

This was referenced Apr 9, 2021

Closed


Closed

@tannergooding
Updating the Vector64/128/256<T> tests to have NotSupported validatio…
ed5db1f
…n for nint/nuint
@tannergooding
Splitting ThrowHelper.ThrowForUnsupportedVectorBaseType into separate…
35764d7
… functions for Numerics vs Intrinsics
@tannergooding
Updating Utf16Utility.Validation to directly use Vector<nuint>
57fc73d
@tannergooding
Don't use the auxiliary type to hold a SIMD type, since it can be tri…
3d4fe63
…vially pulled from the operand instead
@tannergooding
Split the mono handling for ThrowForUnsupportedVectorBaseType into Th…
fa2d443
…rowForUnsupportedNumericsVectorBaseType and ThrowForUnsupportedIntrinsicsVectorBaseType
@tannergooding
Add basic handling for MONO_TYPE_I and MONO_TYPE_U to simd-intrinsics.c
18c2c1a
@tannergooding
Ensure simd-intrinsics.c in Mono handles MONO_TYPE_I and `MONO_TYPE…
b311562
…_U` on relevant code paths
@tannergooding
Ensure we don't assert when encountering synthesized Vector128<nint> …
c150826
…handles
@tannergooding
tannergooding
commented
Apr 14, 2021

Copy link


Copy Markdown

MemberAuthor
Rebased to resolve a conflict, believe I've also resolved the remaining ARM64 issue (it passed on my Windows box).
@tannergooding
tannergooding
commented
Apr 15, 2021

Copy link


Copy Markdown

MemberAuthor
The mono changes look ok to me.
@vargaz, I had to push another commit for Mono: 0f4764d
A bit of the handling existed in mini-amd64.c and so was missed in my first pass, but caught by the tests.

I think I've gotten it all this time, but we'll see what CI says 😄
@tannergooding
tannergooding
commented
Apr 15, 2021

Copy link


Copy Markdown

MemberAuthor
Everything is passing now except for two LLVM AOT scenarios. It isn't clear to me what's wrong here given that the regular Mono leg passed.
@vargaz or @fanyang-mono, could you provide some guidance on how to root cause the failure here?
@tannergooding
tannergooding
commented
Apr 15, 2021

Copy link


Copy Markdown

MemberAuthor
Actually, I may have found it, there is a single line calling out an assert about halfway through the log:
  • Assertion: should not be reached at /__w/1/s/src/mono/mono/mini/mini-llvm.c:580
@tannergooding
tannergooding
commented
Apr 16, 2021

Copy link


Copy Markdown

MemberAuthor
Only test failures are unrelated and due to #51346
This should be ready for final review/merge.
@GrabYourPitchforks
GrabYourPitchforks
commented
Apr 17, 2021

Copy link


Copy Markdown

Member
My small contribution to the review: commit 57fc73d LGTM!
echesakov
echesakov
approved these changes
Apr 20, 2021
View reviewed changes
@echesakovechesakov
left a comment


Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Thank you for your contribution, @tannergooding!
cc @dotnet/jit-contrib
@tannergooding
tannergooding
merged commit 17506ca
into
dotnet:mainApr 20, 2021

This was referenced Apr 21, 2021

Closed

 Merged

@JulieLeeMSFTJulieLeeMSFT
mentioned this pull request
Apr 27, 2021

Closed

@AntonLapounovAntonLapounov
mentioned this pull request
Apr 28, 2021
 Closed

@ghostghost
locked as resolved and limited conversation to collaborators
May 20, 2021
@tannergooding
tannergooding
deleted the

intrinsic-type

branch
July 1, 2025 14:39
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers

@CoffeeFluxCoffeeFluxAwaiting requested review from CoffeeFlux
@lambdageeklambdageekAwaiting requested review from lambdageek
@SamMonoRTSamMonoRTAwaiting requested review from SamMonoRT
@vargazvargazAwaiting requested review from vargaz
@EgorBoEgorBoAwaiting requested review from EgorBo
@imhameedimhameedAwaiting requested review from imhameed

1 more reviewer

@echesakovechesakovechesakov approved these changes
Reviewers whose approvals may not affect merge requirements

Assignees

@tannergoodingtannergooding

Labels

area-CodeGen-coreclrCLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI

Projects


None yet


Milestone

6.0.0

Development

Successfully merging this pull request may close these issues.

Consider expanding Vector<T> to support nint and nuint

7 participants

@tannergooding@fanyang-mono@vargaz@lambdageek@GrabYourPitchforks@echesakov@JulieLeeMSFT