JIT: initial support for stack allocating arrays of GC type#112250
JIT: initial support for stack allocating arrays of GC type#112250AndyAyersMS merged 1 commit intodotnet:mainfrom
Conversation
Add the ability to create a ClassLayout for arrays, and use this to unblock stack allocation for arrays with GC types. Replaces dotnet#111686.
ghost
added
the
area-CodeGen-coreclr
|
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch |
|
@jakobbotsch PTAL This unblocks GC arrays of final types, but for GC arrays of non-final types many stores will use the covariant store check helper which currently causes the array to escape. So only a handful of diffs ( We need both a "only do the covariant store check" variant and a "do the covariant store check and then a checked write barrier" variant. |
| } | ||
| else | ||
| { | ||
| elementSize = genTypeSize(type); |
There was a problem hiding this comment.
I suppose if we really wanted to we could provide a constructor for a class layout for primitive types, which could be used to unify paths like these.
There was a problem hiding this comment.
Seems like that might have been the original intention since we bias the indexes.
There was a problem hiding this comment.
In any case we can just create them as custom layouts now, but I suppose it would be slightly less efficient than this approach.
| } | ||
|
|
||
| comp->lvaSetStruct(lclNum, comp->typGetBlkLayout(blockSize), /* unsafeValueClsCheck */ false); | ||
| comp->lvaSetStruct(lclNum, comp->typGetArrayLayout(clsHnd, length), /* unsafe */ false); |
There was a problem hiding this comment.
Would it make sense to propagate the layout through instead of blockSize? We could probably save a call to getChildType.
There was a problem hiding this comment.
Yeah, I should get rid of the redundant layout fetch.
There was a problem hiding this comment.
Only a small step from there to using layouts everywhere.
I think I should do that first (leaving GC arrays disabled) and verify zero diff, then come back to this and enable gc arrays.
There was a problem hiding this comment.
After poking at it some, I think it might be simpler to take this change first and then revise the entire thing to be more layout centric (getting rid of the special box type, etc).
Thoughts?
|
@jakobbotsch any other feedback? |
* main: (41 commits) Automated bump of chrome version (dotnet#112309) Add `GetDeclaringType` to `PropertyDefinition` and `EventDefinition`. (dotnet#111646) Update the System.ComponentModel.Annotations solution to build in VS (dotnet#112313) JIT: initial support for stack allocating arrays of GC type (dotnet#112250) [main] Update dependencies from dotnet/roslyn (dotnet#112260) Update Xcode casing (dotnet#112307) update the location of assert for REG_ZR check (dotnet#112294) Enable `SA1206`: Keyword ordering (dotnet#112303) Address feedback on dense FrozenDictionary optimization (dotnet#112298) Start regular pri-1 tests runs with native AOT (dotnet#111391) Observe exceptions from _connectionCloseTcs (dotnet#112190) Test failure - SendAsync_RequestVersion20_ResponseVersion20 (dotnet#112232) Fix init race in mono_class_try_get_[shortname]_class. (dotnet#112282) Remove repeated call to DllMain (dotnet#112285) Replace bitvector.h/cpp with ptrArgTP type in gc_unwind_x86.h/inl (dotnet#112268) JIT: Limit 3-opt to 1000 swaps per run (dotnet#112259) [main] Update dependencies from dotnet/icu, dotnet/runtime-assets (dotnet#112120) Update dependencies from https://github.com/dotnet/emsdk build 20250205.3 (dotnet#112223) Fix EventPipe on Android CoreClr. (dotnet#112270) Fix exception handling in the prestub worker (dotnet#111937) ...
2 participants
Add the ability to create a ClassLayout for arrays, and use this to unblock stack allocation for arrays with GC types.
Replaces #111686.