Restore 'computed goto' code generation for the VM loop on VS2022 #1751
Conversation
This patch adds an __assume statement for passed assertations and switches the interpreter loop to using a while-switch instead of a goto-switch loop. This seems to prevent the performance regression experienced on MSVC2022.
|
This wouldn't be the first time the computed goto auto-generation in VS2022 got broken. In these cases it's best to make some small update which restores VS2022 heuristics to trigger. Experimenting a little bit, it really seems that no changes other than making |
vegorov-rbx
changed the title
|
Updated the title to reflect that this is only to restore the optimization that got lost with updated. |
|
I'm sorry to say I just now figured out I was comparing singlestep
None of the |
|
Interesting! Maybe my testing setup was a bit different, but I did see changes in code generation related to dispatch changes in the non-step version when I only applied your edit: well, even clang was recently caught breaking computed goto dispatch optimization in CPython llvm/llvm-project#106846 (comment). |
This patch adds an
__assumestatement for passed assertations (on release builds) and switches the interpreter loop to using a while-switch instead of a goto-switch loop on MSVC. This seems to prevent the performance regression experienced on 2022, and the end result is two less basic blocks in the dispatch logic.__assumesafetyThis patch changes the behavior of assertions on release builds. Any assertion that would throw on a debug build now invokes undefined behavior on a release build. In my testing, this seemed to have a minimal impact on performance on MSVC (within standard error on most benchmarks) so the __assume changes can be reverted if there's a concern.
i9-9900
Compared against 0.666
'luau.exe' change is 7.502% positive on average
Table
i7-1065G7
Compared against 0.666
'luau.exe' change is 4.434% positive on average
Table