[clr-ios] Fix interpreter NullReferenceException with Vector<T> on x64 ios simulator#129012
Open
kotlarmilos wants to merge 2 commits into
Open
[clr-ios] Fix interpreter NullReferenceException with Vector<T> on x64 ios simulator#129012kotlarmilos wants to merge 2 commits into
kotlarmilos wants to merge 2 commits into
Conversation
…-JIT x64 The interpreter only supports 128-bit Vector<T>, but on Mac Catalyst and iOS simulator x64 it was ending up with 256-bit Vector<T>, which caused the NullReferenceException in Vector.get_IsHardwareAccelerated. The runtime already limits Vector<T> to 128-bit for the full interpreter mode, but it wasn't doing so on no-JIT builds where everything is interpreted anyway, so AVX2 on x64 silently bumped it up to 256-bit. Apply the same 128-bit limit whenever the interpreter is the only thing running code. arm64 was never affected since Vector<T> is always 128-bit there. Related dotnet#128898 Fixes dotnet#128901 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
kotlarmilos
changed the title
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Contributor
There was a problem hiding this comment.
Pull request overview
This PR adjusts CoreCLR’s CPU feature initialization so that when execution is interpreter-only (either DOTNET_InterpMode=3 or when the runtime is built without dynamic code compilation/JIT), Vector<T> is constrained to 128-bit on x86/x64. This prevents the runtime from advertising/selecting 256-bit Vector<T> on AVX2-capable x64 machines in configurations where the interpreter can only handle 128-bit vectors.
Changes:
- Detect “interpreter-only” operation as
(InterpMode == 3) || !FEATURE_DYNAMIC_CODE_COMPILED. - Clamp
EXTERNAL_MaxVectorTBitWidthto 128 in interpreter-only mode to prevent enablingInstructionSet_VectorT256/512. - Clamp
EXTERNAL_PreferredVectorBitWidthto 128 in interpreter-only mode to keep vector-width preference consistent with interpreter constraints.
Show a summary per file
| File | Description |
|---|---|
| src/coreclr/vm/codeman.cpp | Updates EEJitManager::SetCpuInfo() to force 128-bit Vector<T> sizing when the interpreter is the only execution engine (including no-JIT builds). |
Copilot's findings
- Files reviewed: 1/1 changed files
- Comments generated: 0
Contributor
|
Tagging subscribers to 'os-ios': @vitek-karas, @kotlarmilos, @steveisok, @akoeplinger |
janvorli
reviewed
Jun 4, 2026
| if (maxVectorTBitWidth != 128 && CLRConfig::GetConfigValue(CLRConfig::EXTERNAL_InterpMode) == 3) | ||
| bool interpreterOnly = CLRConfig::GetConfigValue(CLRConfig::EXTERNAL_InterpMode) == 3; | ||
| #if !defined(FEATURE_DYNAMIC_CODE_COMPILED) | ||
| interpreterOnly = true; |
Member
There was a problem hiding this comment.
Is the crossgen2 also limited to using 128 bit vectors when generating code for the x64 iOS? It seems both interpreter and crossgen2 needs to have the same view on this.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
The interpreter only supports 128-bit Vector, but on Mac Catalyst and iOS simulator x64 it was ending up with 256-bit Vector, which is what caused the NullReferenceException in Vector.get_IsHardwareAccelerated. The runtime already limits Vector to 128-bit for the full interpreter mode, but it wasn't doing so on no-JIT builds where everything is interpreted anyway, so AVX2 on x64 silently bumped it up to 256-bit. This change applies the same 128-bit limit whenever the interpreter is the only thing running code. arm64 was never affected since Vector is always 128-bit there.
Fixes #128901