Introduce local variables with unknown size by snickolls-arm · Pull Request #122638 · dotnet/runtime

snickolls-arm · 2025-12-18T11:23:36Z

Adds ValueSize class for handling sizes that may be unknown at compile time during phases such as value numbering, that aren't concerned with the exact numeric value (only properties such as equivalence etc.). Adds various assertions to areas of value numbering and SSA building with assumptions based on exact size values. Adds LclVarDsc::lvValueSize to produce a ValueSize for a local variable, which provides the criteria for which locals have unknown size at compile time.

Adds lvaLclSymbolicSize for handling locals that may have an unknown size at compile time (SIZE_UNKNOWN). Adds various assertions to areas with assumptions based on concrete size values. Updates parts of value numbering and SSA building to use the symbolic size of the type.

snickolls-arm · 2025-12-18T11:24:03Z

@dotnet/arm64-contrib

dotnet-policy-service · 2025-12-18T11:24:48Z

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

snickolls-arm · 2026-01-06T12:54:20Z

@dotnet/arm64-contrib @dotnet/jit-contrib Please could I have a review for this patch? It's a precursor for supporting the rest of the local variable implementation for SVE Vector<T>, which I can also send if more context is needed.

The ValueSize class represents the size of type for optimization purposes. It allows symbolic representations of sizes that don't have an exact numerical value at compile time, but have some fixed value at runtime. This value must be equivalent for all instances of the same type. The patch replaces any instances of exact sizes being used to construct value numbers with processing that supports ValueSize instead. SSA Semantics are applied with the following considerations: * A load/store can be considered entire when the load/store ValueSize is equivalent to the source/destination ValueSize, and the offset of the operation is zero. Creates a complete definition. * A load/store on a structure can be considered a partial load/store when the ValueSize of the load/store is not equivalent to the source/destination local variable's ValueSize and/or the offset of the operation is not zero. Creates a use-assign definition. * Complete definitions of non-exact ValueSizes propagate definitions as usual. * Partial definitions of non-exact ValueSizes create unique value numbers, as the bounds of the load/store operation cannot be determined. The patch also applies ValueSize to TYP_SIMD on ARM64. ValueSize kinds are added for Vector and Mask types which have unknown size at compile time when supported by the ARM64 Scalable Vector Extension.

snickolls-arm · 2026-01-28T10:54:33Z

@jakobbotsch @SingleAccretion

I've pushed some further value numbering implementation based on your suggestions, and some assertions firing in my branch after introducing ValueSize. This is ready for another pass now.

jakobbotsch

This is looking good to me now, with some nits

* Move ValueSize::FromJitType to gentree.cpp * Demote assertions to debug only

* Remove TARGET_ARM64 ifdefs * Remove assertion * Return NoVN for non-entire vector load/store * Assume inexact field stores are always definitions * Add tests for value numbering Vector<T>

* Handle stores that "may" affect a field, and we cannot tell at compile time * Remove test case

jakobbotsch · 2026-02-05T22:27:40Z

@snickolls-arm Is this ready for another review?

snickolls-arm · 2026-02-06T09:04:36Z

@snickolls-arm Is this ready for another review?

Yes this is ready, thanks.

jakobbotsch · 2026-02-06T16:13:58Z

@SingleAccretion Do you have any other feedback?

SingleAccretion

The change LGTM modulo two comments.

* Base expression VN on local type rather than store type * Implement value numbers for bit casting to a variable size

jakobbotsch · 2026-02-12T18:40:28Z

Thanks!

I think we will need to have a further discussion on the general representation of structs containing vector fields and what we will do about field offsets, sizes and the internal representation of these in the JIT. I think it has potential to become a very infectious change and I am hoping we can find a way to avoid that.

snickolls-arm · 2026-02-16T12:17:12Z

Thanks!
I think we will need to have a further discussion on the general representation of structs containing vector fields and what we will do about field offsets, sizes and the internal representation of these in the JIT. I think it has potential to become a very infectious change and I am hoping we can find a way to avoid that.

Yes absolutely. I can open a separate issue for this if that suits and we can continue discussion there?

Some thoughts I've had to start, which I'll write up in more detail:

I think it's not necessarily required to solve this to get the feature off the ground, at least for JIT and R2R. The EE will always be reporting exact structure offsets, as it reads VL and sets it in the method table of Vector<T>.

For R2R modes, I found safeguards in the interface that prompt recompilation for methods that involve Vector<T>, so it shouldn't be possible to have a size mismatch between some pre-compiled library and the JIT. See here:

runtime/src/coreclr/tools/Common/JitInterface/CorInfoImpl.cs

Line 1167 in 8ef4143

if(method.Context.Target.MaximumSimdVectorLength==SimdVectorLength.None)

If we want to generate complete VL agnostic code in future in NativeAOT mode (i.e. we want to add SVE to the AOT baseline), then we'd need to work out the ABI for these sorts of structures in full, and support this in the ICorJitInfo interface. As you say this will be really infectious, but it could be tackled later on if desired.

Adds `ValueSize` class for handling sizes that may be unknown at compile time during phases such as value numbering, that aren't concerned with the exact numeric value (only properties such as equivalence etc.). Adds various assertions to areas of value numbering and SSA building with assumptions based on exact size values. Adds `LclVarDsc::lvValueSize` to produce a `ValueSize` for a local variable, which provides the criteria for which locals have unknown size at compile time.

github-actionsBot added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label Dec 18, 2025

dotnet-policy-serviceBot added the community-contribution Indicates that the PR has been added by a community member label Dec 18, 2025

snickolls-arm mentioned this pull request Dec 18, 2025
Accelerating Vector<T> with SVE on ARM64 #120599
Open
18 tasks

Merge branch 'main' into unknown-size-locals
e4d752f

build-analysisBot mentioned this pull request Jan 6, 2026
iOS.Device test WorkItemExecutions #122874
Closed

jakobbotsch reviewed Jan 6, 2026
View reviewed changes

Comment threadsrc/coreclr/jit/vartype.h

snickolls-armand others added 2 commits January 7, 2026 14:12

Add ValueSize class for handling unknown size in value numbering
be8f823

Merge branch 'main' into unknown-size-locals
fba7564