Add support for TYP_BYREFLCL_FLDs to VN

[SingleAccretion]

First, the code in fgAddFieldSeqForZeroOffset that was adding zero-offset sequence to LCL_FLD directly was incorrect, because fgAddFieldSeqForZeroOffset adds a sequence for the address that the passed-in node represents, while adding a field sequence to LCL_FLD directly means adding it to the "implicit" LCL_FLD_ADDR it indirects. One can reproduce this issue via code like the following (with JitNoStructPromotion=1):

privatestaticintProblem(StructWithRawFldPtrp){return((StructWithIndex*)p.RawFldPtr)->Index;}structStructWithRawFldPtr{publicnintRawFldPtr;}structStructWithIndex{publicintIndex;publicintValue;}

LCL_FLD long V00 arg0 u:1[+0] Fseq[RawFldPtr, Index] (last use)

The first two commits fix this issue, in fgAddFieldSeqForZeroOffset and similar code in ChangeOper and we now get the lovely combination of LCL_FLD + zero-offset sequence in the map.

LCL_FLD long V00 arg0 u:1[+0] Fseq[RawFldPtr] (last use) ZeroFseq[Index]

That opens a possibility for another bug of course: partial sequences, that is cases where we will have ADD((LCL_FLD PtrToStatic [Zero FldSeq]), OFFSET FldSeq) and fail to incorporate the Zero FldSeq into the PtrToStatic's VN. This is fixed in the third commit.

Part of #58312.
Contributes to #63768.

No diffs as expected.

[ghost]

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

Issue Details

---

First, the code in fgAddFieldSeqForZeroOffset that was adding zero-offset sequence to LCL_FLD directly was incorrect, because fgAddFieldSeqForZeroOffset adds a sequence for the address that the passed-in node represents, while adding a field sequence to LCL_FLD directly means adding it to the "implicit" LCL_FLD_ADDR it indirects. One can reproduce this issue via code like the following:

privatestaticintProblem(StructWithRawFldPtrp){return((StructWithIndex*)p.RawFldPtr)->Index;}structStructWithRawFldPtr{publicnintRawFldPtr;}structStructWithIndex{publicintIndex;publicintValue;}

LCL_FLD long V00 arg0 u:1[+0] Fseq[RawFldPtr, Index] (last use)

The first two commits fix this issue, in fgAddFieldSeqForZeroOffset and similar code in ChangeOper and we now get the lovely combination of LCL_FLD + zero-offset sequence in the map.

LCL_FLD long V00 arg0 u:1[+0] Fseq[RawFldPtr] (last use) ZeroFseq[Index]

That opens a possibility for another bug of course: partial sequences, that is cases where we will have ADD((LCL_FLD PtrToStatic [Zero FldSeq]), OFFSET FldSeq) and fail to incorporate the Zero FldSeq into the PtrToStatic's VN. That is fixed in the third commit.

Part of #58312.
Contributes to #63768.

No diffs are expected.

Author:	SingleAccretion
Assignees:	-
Labels:	area-CodeGen-coreclr, community-contribution
Milestone:	-

[SingleAccretion]

Will assume the Win-Arm64 timeout is not related (it passed on the previous CI run).

@dotnet/jit-contrib

[SingleAccretion]

Pushed some fixes for typos in commit messages (no code changes).

[jakobbotsch]

LGTM, thanks! Just to check my own understanding of the issue here, conceptually we can think of the zero-offset field seqs stored in the lookaside map to mean there is an implict ADD(x, 0) on top of the node with 0 having that field seq, but this code was mixing that up with the field accessed by x?

[SingleAccretion]

Just to check my own understanding of the issue here, conceptually we can think of the zero-offset field seqs stored in the lookaside map to mean there is an implict ADD(x, 0) on top of the node with 0 having that field seq, but this code was mixing that up with the field accessed by x?

Yep, exactly.