JIT: Fix ordering of type initialization and stsfld

[markples]

Insertion of the type initializer before the tree for a stsfld could reorder them inappropriately. This includes those computation in the spill check.

Fixes #72354.

[ghost]

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

Issue Details

---

null

Author:	markples
Assignees:	markples
Labels:	area-CodeGen-coreclr
Milestone:	-

[markples]

need to check the code size regressions

[markples]

So far all are spills of a value around a type initializer call (static = computation). This is exactly the purpose of this change, though presumably the order generally doesn't matter in practice (can't be aliasing as any read/write of static would have already triggered the initialization, so it's just "real" side effects).

[markples]

The previous comment is incorrect. While the particular static should be fine, the computation and type initializer could be accessing a static from some other type and ordering could matter there.

[ghost]

Draft Pull Request was automatically closed for 30 days of inactivity. Please let us know if you'd like to reopen it.

[markples]

@dotnet/jit-contrib This is the fix from long ago that I held off on because I was looking at the small code size regressions. For x64, they were mostly minopts and were due to splitting a tree as is needed because the type initialization needs to go in the middle of it. arm64 numbers follow the same pattern.

[AndyAyersMS]

Always hard to this kind of fix without some code size impact.