[release/6.0] Fix JIT using too wide indirections when returning small structs

[github-actions]

Backport of #68160 to release/6.0

/cc @jakobbotsch

Customer Impact

When returning small structs (< 4 bytes) by indirection (field/array access or pointer/byref dereference), the JIT may instead read 4 bytes from the address. If the address is at the end of a page boundary this may lead to segfault/access violation. Reported by customers in #64802 and #68157.

Testing

Regression test included.

Risk

Low; affects behavior only when directly returning indirections of small structs by reading the correct number of bytes.

[ghost]

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

Issue Details

---

Backport of #68160 to release/6.0

/cc @jakobbotsch

Customer Impact

Testing

Risk

IMPORTANT: If this change touches code that ships in a NuGet package, please make certain that you have added any necessary package authoring and gotten it explicitly reviewed.

Author:	github-actions[bot]
Assignees:	-
Labels:	area-CodeGen-coreclr
Milestone:	-

[JulieLeeMSFT]

@jeffschwMSFT for servicing consider request.

[jeffschwMSFT]

Approved. Can you provide example code and how likely we think that this occurs? We will take for consideration for 6.0.x

[carlossanlop]

@jeffschwMSFT missing servicing approved label.

[jakobbotsch]

Approved. Can you provide example code and how likely we think that this occurs? We will take for consideration for 6.0.x

The miscompilation itself is common. We have 155 cases of the miscompilation in our own libraries when crossgenning.

Code that reproduces the issue looks like:

struct S
{
  <fields so that `S` has size 1 or 2>
}

S SomeFunction()
{
   return <code that is a memory read of `S`, e.g. accessing a field or array of type `S`>;
}

Note that the memory access has to be directly under the return.

The rare part is hitting an actual issue due to the too wide read, which requires the memory address to be right at the end of a page, with the next page not being committed. I believe we have not seen this issue once in our own testing. But we did have two customer reports in #64802 and #68157. The symptom of this is access violation/segfault.

The fix here is to instead of typing a small struct indirection as TYP_INT, we type it as the primitive of the correct type. So it is a very small change in the produced IR which is why I consider the risk low.