JIT: Stop setting class handles for promoted parameter SIMD fields #87967
Conversation
Having these class handles floating around in the JIT is problematic during prejit where the JIT-EE calls allowed on "random" type handles (in this case the type of a field of a struct) is limited. Precursor to dotnet#87917
ghost
added
the
area-CodeGen-coreclr
|
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch Issue DetailsHaving these class handles floating around in the JIT is problematic during prejit where the JIT-EE calls allowed on "random" type handles (in this case the type of a field of a struct from the IL) is limited. Precursor to #87917 No diffs expected.
|
|
/azp run runtime-coreclr jitstress, runtime-coreclr libraries-jitstress, runtime-coreclr outerloop |
|
Azure Pipelines successfully started running 3 pipeline(s). |
|
cc @dotnet/jit-contrib PTAL @BruceForstall For some context we removed the requirement for SIMD locals to have class handles a while ago (back around #83036). However, the requirement remained for promoted SIMD fields of parameters; this PR removes it for those as well, and stops setting them. There were a few cases in the backend that were using the handle for ABI purposes. This itself was a bit questionable since the ABI details for passing the type of a field does not necessarily have any relation to the ABI details of passing the parent. |
Having these class handles floating around in the JIT is problematic during prejit where the JIT-EE calls allowed on "random" type handles (in this case the type of a field of a struct from the IL) is limited.
Precursor to #87917
No diffs expected.