Use explicit destinations in codegen to avoid uselessly jumping around. #14890
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
sjrd
force-pushed
the
codegen-destinations
branch
3 times, most recently
from
75c1f23 to
d86e68b
Compare
Previously, the codegen's main method `genLoad` always generated code that loaded the value on the stack before continuing. There were a number of situations where `genLoad` would be directly followed by unconditional jumps to instructions performing more jumps, returns and throws. This generated more spurious jumps than necessary, along with artifact dead code. We solve these limitations by introducing `LoadDestination`s that specify the destination of a loaded value: * FallThrough: as previously, load the value on the stack and continue. * Jump(label): load the value on the stack and jump to the given label. * Return: return the value from the enclosing method. * Throw: throw the value. We generalize `genLoad` as `genLoadTo`, taking a specific destination for the loaded value. `genLoadTo` can "push down" its destination into all control flow structures (except `Try`s, because of their cleanups). With that, when we get to the end of what amounts to "basic blocks", we know exactly the ultimate destination of the loaded value. We can therefore directly jump, return or throw to the final destination. This produces less bytecode, notably because fewer labels are necessary. For example, the method: def abs(x: Int): Int = if x < 0 then -x else x previously generated bytecode like ILOAD 1 ICONST_0 IF_ICMPGE Label(1) ILOAD 1 INEG GOTO Label(2) Label(1): ILOAD 1 Label(2): IRETURN Now, instead of jumping to Label(2), we directly perform an IRETURN: ILOAD 1 ICONST_0 IF_ICMPGE Label(1) ILOAD 1 INEG IRETURN Label(1): ILOAD 1 IRETURN While the changes are not very impressive on that simple example, they become more important in more complex cases, notably with pattern matching. Examples can be found in the changed bytecode tests. An added benefit is that `genLoadTo` knows when loading a value results in an unconditional control flow change (jump, return or throw). It can then avoid inserting any useless adaptation. This removes all the dead bytecode that the codegen used to generate as artifacts of its own compilation scheme. (It will still generate dead bytecode if the original source code/inlined code contains dead code.)
sjrd
force-pushed
the
codegen-destinations
branch
from
d86e68b to
4a2889f
Compare
sjrd
changed the title
sjrd
commented
Apr 13, 2022
Comment on lines
-595
to
-600
| case Labeled(bind, expr) if tpeTK(body) == UNIT => | ||
| // this is the shape of tailrec methods | ||
| val loop = programPoint(bind.symbol) | ||
| markProgramPoint(loop) | ||
| genLoad(expr, UNIT) | ||
| bc goTo loop |
There was a problem hiding this comment.
This optimization is now performed "by construction" of the generic LoadDestination infrastructure. :)
sjrd
commented
Apr 13, 2022
Comment on lines
-805
to
-806
| case (_: Return) | Block(_, (_: Return)) => () | ||
| case (_: Apply) | Block(_, (_: Apply)) if trimmedRhs.symbol eq defn.throwMethod => () |
There was a problem hiding this comment.
These two optimizations are also taken care of by the general LoadDestination infrastructure.
|
Ping @lrytz ? |
lrytz
approved these changes
Apr 29, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
CI for now. This needs some cleanup and better tests that the bytecode is indeed improved in a number of situations. (notably with pattern matching)Previously, the codegen's main method
genLoadalways generated code that loaded the value on the stack before continuing. There were a number of situations wheregenLoadwould be directly followed by unconditional jumps to instructions performing more jumps, returns and throws. This generated more spurious jumps than necessary, along with artifact dead code.We solve these limitations by introducing
LoadDestinations that specify the destination of a loaded value:FallThrough: as previously, load the value on the stack and continue.Jump(label): load the value on the stack and jump to the given label.Return: return the value from the enclosing method.Throw: throw the value.We generalize
genLoadasgenLoadTo, taking a specific destination for the loaded value.genLoadTocan "push down" its destination into all control flow structures (exceptTrys, because of their cleanups). With that, when we get to the end of what amounts to "basic blocks", we know exactly the ultimate destination of the loaded value. We can therefore directly jump, return or throw to the final destination.This produces less bytecode, notably because fewer labels are necessary. For example, the method:
previously generated bytecode like
Now, instead of jumping to
Label(2), we directly perform anIRETURN:While the changes are not very impressive on that simple example, they become more important in more complex cases, notably with pattern matching. Examples can be found in the changed bytecode tests.
An added benefit is that
genLoadToknows when loading a value results in an unconditional control flow change (jump, return or throw). It can then avoid inserting any useless adaptation. This removes all the dead bytecode that the codegen used to generate as artifacts of its own compilation scheme. (It will still generate dead bytecode if the original source code/inlined code contains dead code.)