[release/10.0-rc1] Fixup some Vector<T> function lookups to use the right name/type #119069
Conversation
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
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
…lysis (#118769) A couple times in the past I needed a way to say "if X is not part of the program, eliminate the entire basic block". We can do this for allocated types (this is how branches under `is` checks elimination works), but we can't do this for more general "characteristics". This introduces a mechanism where AOT compiler and CoreLib (or System.Private.* universe in general) can define whole program tags such as "whole program has X in it" and CoreLib can condition code on the presence of this tag. This is easier shown than described, so I extracted the first use of this into a separate commit. In this commit, we eliminate code that tries looking for `StackTraceHiddenAttribute` if we know the whole program has no `StackTraceHiddenAttribute` in it. With this code eliminated, #118640 can then eliminate all custom attributes on methods, which in turn plays into #118718 and we can eliminate enum boxing even when StackTraceSupport is not set to false (right now #118718 really needs the StackTraceSupport=false to get rid of boxed enums; we get more boxed enums from method attributes). We have a new node that represents the characteristic. The node can be dropped into the graph wherever needed. ILScanner then uses this to condition parts of the method body on this characteristic node. We need similar logic in the substitution IL provider because we need to guarantee that RyuJIT is not going to see basic blocks we didn't scan. So we treat it as a substitution during codegen phase too.
Contributing towards [#115479](#115479) Contains implementations for the set of [SVE2 FP APIs](#94018 (comment)), aside from `ConvertToSingleOdd` and `ConvertToSingleOddRoundToOdd`. This is due to concerns I have about the API proposal for these intrinsics being incorrect, when I have a resolution to [my comments](#94018 (comment)) on this they will be implemented.
The assertion only ended up printing stderr, but it would be useful to have all the information about the command that was run (the exit code, stdout).
and if the GCGen0MaxBudget config is specified, always honor it including for DATAS
With large block counts, the CFG convergence takes a long time and performs a lot of Meets, allocating a new Dictionary for each Value in each block. This adds up to gigabytes of allocations in the process. Ideally we would fix the performance issue with some optimization, but I'm still working on a proper solution. To fix the issue for .NET 10 in the meantime, we can add a limit to the number of iterations to bail out if we reach an excessively large number of iterations. The largest number of iterations in the runtime build is 2600, so 10,000 seems fairly reasonable. The build time of the project in issue #118121 is around ~20 seconds with 10,000 iterations and ~70 seconds with 20,000.
Mop-up commits from the end of the merge window for RC1
…8829) This lets us keep some of the constant-time indexing advantages of the IList iterator, without the GVM overhead of Select. There is a small size increase here, but nowhere near the cost of the GVM. In a pathological generated example for GVMs the cost was: 1. .NET 9: 12 MB 2. .NET 10 w/out this change: 2.2 MB 3. .NET 10 w/ this change: 2.3 MB In a real-world example (AzureMCP), the size attributed to System.Linq was: 1. .NET 9: 1.2 MB 2. .NET 10 w/out this change: 340 KB 3. .NET 10 w/ this change: 430 KB This seems like a good tradeoff. We mostly keep the algorithmic complexity the same across the size/speed-opt versions, and just tradeoff on the margins. We could probably continue to improve this in the future.
…t/filters from C++/CLI (#118905) * JIT: fix issue with EH clause class types for fault/filters from C++/CLI C++/CLI appears to leave the CORINFO_EH_CLAUSE ClassToken/FilterOffset union set to some nonzero value for fault/filter clauses. The JIT currently just passes this value along to the runtime. If a method with such a nonzero field is inlined into a dynamic method, this trips up a check in the runtime where a nonzero entry for such a field is interpreted as a class handle, even for fault/filter clauses where it should be ignored. Tolerate this by zeroing the field in the JIT. Note this could not have happened in pre .NET10 as methods with EH could not be inlined, so a dynamic method would never see such an EH clause, and in non-dynamic methods this field is ignored for faults and filters. Fixes #118837. * review feedback * zero eh table on alloc/realloc --------- Co-authored-by: Andy Ayers <[email protected]>
* Add trim analysis for implicit constructors * Fix RequiresExcludeStatics test * Fix test for native AOT * Fix test, move to base analyzer * Clean up whitespace * Fix RegexLWCGCompiler annotations This was warning on the implicit ctor. --------- Co-authored-by: Sven Boemer <[email protected]>
tannergooding
added
Servicing-consider
EgorBo
approved these changes
Aug 25, 2025
JulieLeeMSFT
approved these changes
Aug 25, 2025
|
@tannergooding / @JulieLeeMSFT - RC1 is already locked down at this point. We need to target RC2 for this fix. |
jeffhandley
requested review from
marek-safar,
sbomer and
MichalStrehovsky
as code owners
jeffhandley
changed the title
dotnet-policy-service
bot
added
the
linkable-framework
|
@tannergooding I tried to rebase this onto |
jeffhandley
changed the title
|
This PR is replaced by #119080. |
This was referenced Aug 26, 2025
jeffhandley
removed
the
Servicing-consider
Thanks! |
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.
Backport of #119068 to release/10.0 (RC2)
/cc @tannergooding
Customer Impact
Developers using
Vectorcomparison APIs would see incorrect behavior for some overloads; while those usingSquareRootwould see reduced performance.Regression
The regressions were introduced as part of the several refactorings that removed the independent
simdashwintrinsicsupport and changed it to reuse thehwintrinsicpaths.The general issue is that the
System.Numericsvector API surface differs slightly from the modernSystem.Runtime.IntrinsicsAPI surface. Namely it exposes some "legacy" overloads of the comparison APIs that returnVector<int>for comparisons involvingVector<float>and which uses a different name for a few APIs. While most of these special edge cases were handled as part of removing thesimdashwintrinsicsupport, a couple were missed.Testing
An explicit test covering the customer reported regression was added. Manual validation of the related scenarios and codegen was done.
Risk
Low. This is simply adding the long-existing flags to the table relevant table entries to ensure they go down the right code paths. There isn't really any "net new" code here which could introduce risk.