-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Fix #70849: Print LARGEJMP instruction on ARM64 #71094
Conversation
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch Issue DetailsThese changes address #70849 by implementing the special case of printing the LARGEJMP pseudo-instruction in
|
@BruceForstall PTAL. I thought I'd tackle this in my spare time between the ARM64 hot/cold splitting PR and getting started on crossgen2. Thanks! |
pidJmp->idIns(INS_b); | ||
pidJmp->idInsFmt(IF_T2_J2); | ||
pidJmp->idInsSize(emitInsSize(IF_T2_J2)); | ||
pidJmp->idjShort = 0; |
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.
This is set to 1 above and then 0 here. Are both needed? Does pidJmp point to a different piece of memory in these cases?
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.
idjShort
is initially set to 1 to satisfy an assert in emitDispInsHelp
, as we emit a short conditional branch first for the pseudo-instruction. While the following unconditional branch is long (thus suggesting idjShort
should be 0), I don't see any asserts in its control flow through emitDispInsHelp
that require idjShort == 0
, though that could change in the future.
This looks weird because pidJmp
is used to emit both the short conditional and the long unconditional branches, but I think the logic is correct.
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.
The memory pointed to gets zeroed between uses (so zeroing isn't required, perhaps, but in this case it's best to be clear and have it).
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.
I agree, clarity is important. It might be worth a comment to explain that two different things are being done through the ptr but it's not a problem without.
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.
This looks great, just one request.
Can you share a before/after example of the output?
emitter::emitDispIns supports printing LARGEJMP pseudo-instructions on ARM32, but not on ARM64. This method has been re-architected on ARM64 to support printing LARGEJMP instructions on ARM64.
7645db7
to
27b79c7
Compare
Sure thing. Consider the following (large) conditional branch: The JIT converts this instruction to a "jump stub" by inverting the condition and emitting a short branch, followed by an unconditional branch to the original target. Previously,
(note the missing register argument, and no hex encoding of the instruction) This jump stub now prints correctly, as so:
The hex encodings are now present, and both instructions in the jump stub are printed correctly. |
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.
Looks good.
These changes address #70849 by implementing the special case of printing the LARGEJMP pseudo-instruction in
emitter::emitDispIns
on ARM64. To achieve functional and organizational parity between the ARM32 and ARM64 implementations,emitter::emitDispIns
has been re-architected as so:emitter::emitDispInsHelp
(just like on ARM32). The method now checks for the special LARGEJMP case, and calls the appropriate method.