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
JitArm64: Never check downcount on block entry #11191
JitArm64: Never check downcount on block entry #11191
Conversation
3f59a05
to
cfe9c1a
Compare
Console error & backtrace when starting Rogue Leader. Error happens at startup.
|
3c3953e
to
696cd0c
Compare
Thanks! Fixed. |
I brought this up on discord. Posting it here so it doesn’t get lost. RS2 freezes when switching to the targeting computer (Y Button). Usually doesn’t freeze but this is from a dtm file that can catch it every time. I can share it if needed. |
@dvessel Can you check if this patch fixes it?
The reason why I didn't push this patch to the pull request is because if I were to push without rebasing, the buildbot would get upset, and if I were to rebase, your DTM might not sync anymore. If you can confirm that this fixes it, I'll rebase and push. |
Rebased the PR and still freezes. Applied patch and now getting this error at the same point where it freezes: The dtm file doesn’t depend on a save state so rebasing is fine.
|
696cd0c
to
8e76cb3
Compare
My concern wasn't about savestates not loading, it was about the inputs desyncing. But okay, if it syncs for you after rebasing, I suppose we haven't had any sync-breaking changes since you made the DTM. I've rebased the PR and added a patch that should fix the assert you reported getting. Does it also fix the freeze, or is that still happening? If it's still happening, could you bisect within the PR? |
It works! Thanks for the fix. |
9e302e7
to
00cede9
Compare
00cede9
to
46ddd54
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.
I've added some minor comments. Feel free to completely ignore me though.
Jumping between linked blocks currently works as follows: First, at the end of the first block, we check if the downcount is greater than zero. If it is, we jump to the `normalEntry` of the block. So far so good. But if the downcount wasn't greater than zero, we jump to the `checkedEntry` of the block, which checks the downcount *again* and then jumps to `do_timing` if it's less than zero (which seems like an off by one error - Jit64 doesn't do anything like this). This second check is rather redundant. Let's jump to `do_timing` where we previously jumped to `checkedEntry`. Jit64 doesn't check the downcount on block entry. See 5236dc3.
It's now always identical to normalEntry.
46ddd54
to
e0eb138
Compare
Now block link nearcode is back to a length of three instructions. Unfortunately, the code I'm adding to Jit.cpp ends up being a bit messy because we need to handle the case of already being in farcode...
e0eb138
to
d2c5d79
Compare
Jumping between linked blocks currently works as follows: First, at the end of the first block, we check if the downcount is greater than zero. If it is, we jump to the
normalEntry
of the block. So far so good. But if the downcount wasn't greater than zero, we jump to thecheckedEntry
of the block, which checks the downcount again and then jumps todo_timing
if it's less than zero (which seems like an off by one error – Jit64 doesn't do anything like this). This second check is rather redundant. Let's jump todo_timing
where we previously jumped tocheckedEntry
.Jit64 doesn't check the downcount on block entry. See PR #7634.