Unbreak YKD_OPT=0.
#1523
Merged
Unbreak YKD_OPT=0.
#1523
Conversation
This file contains 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
When adding support for loop peeling, we forgot that loops are only
peeled when optimisations are turned on. When they were turned off, we
generated code with no backjump e.g.:
```
; %294: ptr = load %293
mov rsi, [rdi+0x588]
; header_end [...]
; Deopt ID for guard 0
push rsi
mov rsi, 0x00
```
Notice no `jmp` between `header_end` and `Deopt`. That meant that we
fell through to whichever guard's deopt happened to come first, with
confusing results. For example, before this commit the new test
`ykd_opt_off` would print:
```
10
9
8
7: 7
```
even though the code shows this is clearly "impossible":
```rust
if (i < 7)
printf("7: ");
```
This commit not only fixes that, but brings a bit more order to three
kinds of traces we can compile: "header only" traces (most tests, and
when `YKD_OPT=0`); "header and body" traces (with loop peeling); and
"side traces". A new `TraceKind` captures these, and allows us to
simplify quite a bit of code in the x64 backend, which no longer has to
guess what kind of trace it has.
Perhaps inevitably this also showed up a few tests where we'd muddled
header and body.
Closed
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.
When adding support for loop peeling, we forgot that loops are only peeled when optimisations are turned on. When they were turned off, we generated code with no backjump e.g.:
Notice no
jmpbetweenheader_endandDeopt. That meant that we fell through to whichever guard's deopt happened to come first, with confusing results. For example, before this commit the new testykd_opt_offwould print:even though the code shows this is clearly "impossible":
This commit not only fixes that, but brings a bit more order to three kinds of traces we can compile: "header only" traces (most tests, and when
YKD_OPT=0); "header and body" traces (with loop peeling); and "side traces". A newTraceKindcaptures these, and allows us to simplify quite a bit of code in the x64 backend, which no longer has to guess what kind of trace it has.Perhaps inevitably this also showed up a few tests where we'd muddled header and body.