JitArm64: FIFO optimization improvements #10046
Conversation
JosJuice
force-pushed
the
jitarm64-improve-const-stores
branch
from
e1046a4
to
1550689
Compare
|
I pulled this PR and rebased on master upstream |
JosJuice
force-pushed
the
jitarm64-improve-const-stores
branch
3 times, most recently
from
0129a58
to
4f4ba0d
Compare
|
Hope this isn’t annoying. Going through old PR’s with these numbers. Figured out a jank way to measure frame times while I do other things. No real changes here. Apple M1, f-zero intro and a few seconds of game play.
|
JosJuice
force-pushed
the
jitarm64-improve-const-stores
branch
from
4f4ba0d
to
6ff98fc
Compare
JitArm64 port of 789975e.
JosJuice
force-pushed
the
jitarm64-improve-const-stores
branch
from
6ff98fc
to
77540f2
Compare
| @@ -806,6 +850,12 @@ bool JitArm64::DoJit(u32 em_address, JitBlock* b, u32 nextPC) | |||
| gpr.Start(js.gpa); | |||
| fpr.Start(js.fpa); | |||
|
|
|||
| if (js.noSpeculativeConstantsAddresses.find(js.blockStart) == | |||
| js.noSpeculativeConstantsAddresses.end()) | |||
There was a problem hiding this comment.
C++20 has unordered_set::contains which might be easier to read (though it probably has no performance difference). (The same applies to the x64 JIT.)
There was a problem hiding this comment.
I think I'd prefer to do it like this for now and then move them over all at once. (This isn't the first place in JitArm64 where we're using this idiom.)
There was a problem hiding this comment.
That's fine. (I also noticed that the x64 JIT uses camelCase in its IntializeSpeculativeConstants, which is something that can be fixed elsewhere).
Maybe "tail call" isn't quite the right term for what this code is doing, since it's jumping to the dispatcher rather than returning, but it's the same optimization as for a tail call.
JosJuice
force-pushed
the
jitarm64-improve-const-stores
branch
from
77540f2
to
351d095
Compare
JitArm64 port of PR #4123.