-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for TYP_BYREF
LCL_FLD
s to VN
#64501
Conversation
Tagging subscribers to this area: @JulieLeeMSFT Issue DetailsFirst, the code in private static int Problem(StructWithRawFldPtr p)
{
return ((StructWithIndex*)p.RawFldPtr)->Index;
}
struct StructWithRawFldPtr
{
public nint RawFldPtr;
}
struct StructWithIndex
{
public int Index;
public int Value;
} LCL_FLD long V00 arg0 u:1[+0] Fseq[RawFldPtr, Index] (last use) The first two commits fix this issue, in LCL_FLD long V00 arg0 u:1[+0] Fseq[RawFldPtr] (last use) Zero Fseq[Index] That opens a possibility for another bug of course: partial sequences, that is cases where we will have Part of #58312. No diffs are expected.
|
Will assume the Win-Arm64 timeout is not related (it passed on the previous CI run). @dotnet/jit-contrib |
53d8614
to
8608afa
Compare
Pushed some fixes for typos in commit messages (no code changes). |
"fgAddFieldSeqForZeroOffset"'s contract is that it is passed an *address*. If that address is a LCL_FLD, we must use the "zero-offset sequence map", not the sequence of LCL_FLD itself, as that represents LCL_FLD's own value, not the value it produces (LCL_FLD == IND(LCL_FLD_ADDR), and LCL_FLD's sequence is the one attached to LCL_FLD_ADDR, not IND).
8608afa
to
c93785c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
?
Yep, exactly. |
First, the code in
fgAddFieldSeqForZeroOffset
that was adding zero-offset sequence toLCL_FLD
directly was incorrect, becausefgAddFieldSeqForZeroOffset
adds a sequence for the address that the passed-in node represents, while adding a field sequence toLCL_FLD
directly means adding it to the "implicit"LCL_FLD_ADDR
it indirects. One can reproduce this issue via code like the following (withJitNoStructPromotion=1
):The first two commits fix this issue, in
fgAddFieldSeqForZeroOffset
and similar code inChangeOper
and we now get the lovely combination ofLCL_FLD
+ zero-offset sequence in the map.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 theZero FldSeq
into thePtrToStatic
's VN. This is fixed in the third commit.Part of #58312.
Contributes to #63768.
No diffs as expected.