Change lowering of gc preserve #34379
Merged
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
This fixes #34247 by changing the way gc preserve is lowered. Instead of lowering it in a macro, lower it in the frontend. This allows us to use an SSA value directly for the return token of the gc begin expression. This bypasses the slot-renaming pass of the compiler, thus preventing the compiler from trying to save and restore the token. Of course, this kind of code would generally not be legal (because it uses an SSA value outside of the regular domination relation), but since this is a julia restriction, not an LLVM restriction, we can simply exempt gc_begin tokens from this particular validation. This works fine at the LLVM level also, because it doesn't have this particular restriction. It also doesn't have the same correctness problems as doing the same for non-token values, as the tokens get lowered away by the try/catch lowering before reaching the LLVM backend.
vtjnash
approved these changes
Jan 14, 2020
KristofferC
pushed a commit
that referenced
this pull request
Jan 15, 2020
This fixes #34247 by changing the way gc preserve is lowered. Instead of lowering it in a macro, lower it in the frontend. This allows us to use an SSA value directly for the return token of the gc begin expression. This bypasses the slot-renaming pass of the compiler, thus preventing the compiler from trying to save and restore the token. Of course, this kind of code would generally not be legal (because it uses an SSA value outside of the regular domination relation), but since this is a julia restriction, not an LLVM restriction, we can simply exempt gc_begin tokens from this particular validation. This works fine at the LLVM level also, because it doesn't have this particular restriction. It also doesn't have the same correctness problems as doing the same for non-token values, as the tokens get lowered away by the try/catch lowering before reaching the LLVM backend. (cherry picked from commit 07a16d6)
28 tasks
KristofferC
pushed a commit
that referenced
this pull request
Jan 15, 2020
This fixes #34247 by changing the way gc preserve is lowered. Instead of lowering it in a macro, lower it in the frontend. This allows us to use an SSA value directly for the return token of the gc begin expression. This bypasses the slot-renaming pass of the compiler, thus preventing the compiler from trying to save and restore the token. Of course, this kind of code would generally not be legal (because it uses an SSA value outside of the regular domination relation), but since this is a julia restriction, not an LLVM restriction, we can simply exempt gc_begin tokens from this particular validation. This works fine at the LLVM level also, because it doesn't have this particular restriction. It also doesn't have the same correctness problems as doing the same for non-token values, as the tokens get lowered away by the try/catch lowering before reaching the LLVM backend. (cherry picked from commit 07a16d6)
KristofferC
pushed a commit
that referenced
this pull request
Jan 17, 2020
This fixes #34247 by changing the way gc preserve is lowered. Instead of lowering it in a macro, lower it in the frontend. This allows us to use an SSA value directly for the return token of the gc begin expression. This bypasses the slot-renaming pass of the compiler, thus preventing the compiler from trying to save and restore the token. Of course, this kind of code would generally not be legal (because it uses an SSA value outside of the regular domination relation), but since this is a julia restriction, not an LLVM restriction, we can simply exempt gc_begin tokens from this particular validation. This works fine at the LLVM level also, because it doesn't have this particular restriction. It also doesn't have the same correctness problems as doing the same for non-token values, as the tokens get lowered away by the try/catch lowering before reaching the LLVM backend. (cherry picked from commit 07a16d6)
KristofferC
pushed a commit
that referenced
this pull request
Apr 11, 2020
This fixes #34247 by changing the way gc preserve is lowered. Instead of lowering it in a macro, lower it in the frontend. This allows us to use an SSA value directly for the return token of the gc begin expression. This bypasses the slot-renaming pass of the compiler, thus preventing the compiler from trying to save and restore the token. Of course, this kind of code would generally not be legal (because it uses an SSA value outside of the regular domination relation), but since this is a julia restriction, not an LLVM restriction, we can simply exempt gc_begin tokens from this particular validation. This works fine at the LLVM level also, because it doesn't have this particular restriction. It also doesn't have the same correctness problems as doing the same for non-token values, as the tokens get lowered away by the try/catch lowering before reaching the LLVM backend.
BioTurboNick
pushed a commit
to BioTurboNick/julia
that referenced
this pull request
Apr 13, 2020
This fixes JuliaLang#34247 by changing the way gc preserve is lowered. Instead of lowering it in a macro, lower it in the frontend. This allows us to use an SSA value directly for the return token of the gc begin expression. This bypasses the slot-renaming pass of the compiler, thus preventing the compiler from trying to save and restore the token. Of course, this kind of code would generally not be legal (because it uses an SSA value outside of the regular domination relation), but since this is a julia restriction, not an LLVM restriction, we can simply exempt gc_begin tokens from this particular validation. This works fine at the LLVM level also, because it doesn't have this particular restriction. It also doesn't have the same correctness problems as doing the same for non-token values, as the tokens get lowered away by the try/catch lowering before reaching the LLVM backend. (cherry picked from commit 07a16d6)
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.
This fixes #34247 by changing the way gc preserve is lowered.
Instead of lowering it in a macro, lower it in the frontend.
This allows us to use an SSA value directly for the return token
of the gc begin expression. This bypasses the slot-renaming pass
of the compiler, thus preventing the compiler from trying to save
and restore the token. Of course, this kind of code would generally
not be legal (because it uses an SSA value outside of the regular
domination relation), but since this is a julia restriction, not
an LLVM restriction, we can simply exempt gc_begin tokens from this
particular validation. This works fine at the LLVM level also, because
it doesn't have this particular restriction. It also doesn't have
the same correctness problems as doing the same for non-token values,
as the tokens get lowered away by the try/catch lowering before reaching
the LLVM backend.