Add explicit null checks for zero-offset struct fields

[SingleAccretion]

Fixes #77640.

We expect some unavoidable regressions.

[ghost]

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

Issue Details

---

Fixes #77640.

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

[SingleAccretion]

This comment is not correct; ldflda is required by the specification to throw on null addresses, immediately.

[SingleAccretion]

The diffs are relatively minor, the only large regressions are in MinOpts context from coreclr_tests (on some targets).

This fix will significantly simplify the ADDR(FIELD) => FIELD_ADDR transition.

@dotnet/jit-contrib

[EgorBo]

Reminds me that we used to tolerate this sort of issues and treat pointers to value types as never null.

[EgorBo]

Although the diffs don't look too bad in FullOpts so presumably it's fine?

[jakobbotsch]

Some of the diffs do look to be in some scary functions:

           3 (20.00 % of base) : 3668.dasm - ConfiguredValueTaskAwaiter[System.__Canon]:get_IsCompleted():bool:this
           3 (20.00 % of base) : 3851.dasm - ConfiguredValueTaskAwaiter[System.__Canon]:GetResult():System.__Canon:this
           3 (20.00 % of base) : 26284.dasm - System.Runtime.CompilerServices.AsyncValueTaskMethodBuilder:SetException(System.Exception):this
           3 (20.00 % of base) : 16608.dasm - System.Runtime.CompilerServices.ValueTaskAwaiter`1[System.__Canon]:get_IsCompleted():bool:this
           3 (20.00 % of base) : 16609.dasm - System.Runtime.CompilerServices.ValueTaskAwaiter`1[System.__Canon]:GetResult():System.__Canon:this
           3 (10.00 % of base) : 16777.dasm - System.Runtime.CompilerServices.AsyncTaskMethodBuilder:AwaitUnsafeOnCompleted[YieldAwaiter,<MultipleSerial>d__23[System.__Canon]](byref,byref):this
           3 (0.53 % of base) : 14294.dasm - System.Collections.Generic.Dictionary`2[uint,System.__Canon]:FindValue(uint):byref:this

We should keep an eye on related benchmarks and/or double check that the diffs in these are not impactful.

[EgorBo]

Some of the diffs do look to be in some scary functions:

           3 (20.00 % of base) : 3668.dasm - ConfiguredValueTaskAwaiter[System.__Canon]:get_IsCompleted():bool:this
           3 (20.00 % of base) : 3851.dasm - ConfiguredValueTaskAwaiter[System.__Canon]:GetResult():System.__Canon:this
           3 (20.00 % of base) : 26284.dasm - System.Runtime.CompilerServices.AsyncValueTaskMethodBuilder:SetException(System.Exception):this
           3 (20.00 % of base) : 16608.dasm - System.Runtime.CompilerServices.ValueTaskAwaiter`1[System.__Canon]:get_IsCompleted():bool:this
           3 (20.00 % of base) : 16609.dasm - System.Runtime.CompilerServices.ValueTaskAwaiter`1[System.__Canon]:GetResult():System.__Canon:this
           3 (10.00 % of base) : 16777.dasm - System.Runtime.CompilerServices.AsyncTaskMethodBuilder:AwaitUnsafeOnCompleted[YieldAwaiter,<MultipleSerial>d__23[System.__Canon]](byref,byref):this
           3 (0.53 % of base) : 14294.dasm - System.Collections.Generic.Dictionary`2[uint,System.__Canon]:FindValue(uint):byref:this

We should keep an eye on related benchmarks and/or double check that the diffs in these are not impactful.

I assume these all are small functions judging by the relative diffs and are inlined in the real world where null-checks might be folded

[SingleAccretion]

I assume these all are small functions judging by the relative diffs and are inlined in the real world where null-checks might be folded

That would be my assumption as well. For reference, the large relative diffs mainly come from cases where have a method that immediately tail-calls another (a member function).