You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
MSVC is able to merge a normal jump to a computed jump into a single computed jump.
It does, however, seems quite picky about when it will merge the goto and computed branch for the switch into a single branch, but it can be persuaded to do so (at least on this online compiler):
It seems that MSVC is quite keen on merging similar code paths.
If the code immediately before the dispatch: label resembles DISPATCH to closely, we get the same code as if a default we used.
If all the illegal opcode cases are written as oparg = opcode; instead of oparg = LITERAL_VALUE then the cases are merged and we get jump merging, but with an extra memory read. This might be an acceptable compromise as it should still help the branch predictor.
I don't think we can directly test that the code is compiling as we wish.
We could check it manually initially and then rely on performance testing to show up any regressions.
For that we would need a Windows machine for performance testing.
The text was updated successfully, but these errors were encountered:
We now generate a complete set of labels, so that MSCV can eliminate any bounds checks.
Beyond that it is tricky trying to second guess the compiler.
With the JIT framework we can potentially generate a tailcall based implementation of the interpreter which fix this problem and benefit performance on all platforms. #642
MSVC is able to merge a normal jump to a computed jump into a single computed jump.
It does, however, seems quite picky about when it will merge the goto and computed branch for the switch into a single branch, but it can be persuaded to do so (at least on this online compiler):
https://godbolt.org/z/nss93dr7T
It seems that MSVC is quite keen on merging similar code paths.
If the code immediately before the dispatch: label resembles DISPATCH to closely, we get the same code as if a default we used.
If all the illegal opcode cases are written as oparg = opcode; instead of oparg = LITERAL_VALUE then the cases are merged and we get jump merging, but with an extra memory read. This might be an acceptable compromise as it should still help the branch predictor.
I don't think we can directly test that the code is compiling as we wish.
We could check it manually initially and then rely on performance testing to show up any regressions.
For that we would need a Windows machine for performance testing.
The text was updated successfully, but these errors were encountered: