aarch64: Simplify and improve handling of conditionals#13315
Open
alexcrichton wants to merge 3 commits intobytecodealliance:mainfrom
Open
aarch64: Simplify and improve handling of conditionals#13315alexcrichton wants to merge 3 commits intobytecodealliance:mainfrom
alexcrichton wants to merge 3 commits intobytecodealliance:mainfrom
Conversation
This commit refactors the aarch64 backend to match the x64 backend with
how it handles conditionals. Specifically there's now a "narrow waist"
of a `CondResult` type which is used for `trapnz`, `trapz`, `select`,
`icmp`, `brif`, and `select_spectre_guard`. This means that any lowering
optimizations to handle conditionals are equally applied to all of these
locations. Notably the smattering of optimizations and implementations
across these instructions have all been deduplicated an unified. Codegen
of `trap{n,}z` is much better than before, and minor optimizations such
as testing if an 8-bit value is 0 are now improved across the board.
Finally, jumping after comparing a less-than-64-bit value now will use a
32-bit comparison instruction instead of a 64-bit comparison
instruction, sometimes eliding the need to extend a 32-bit value to a
64-bit value.
During this refactoring the method of comparing 128-bit integers was
copied over from the x64 backend as well. This additionally
significantly improves codegen over the previous iteration.
The end result is that it should be significantly easier to apply
optimizations and bug fixes in the future. For example some float
comparison orderings are not yet currently supported in the aarch64
backend, but are supported in the x64 backend, and this paves the way to
make it much easier to add support for this feature as only one
comparison-generation location need be updated and a small set of
do-something-with-a-comparison locations will be specialized to the
condition necessary.
github-actions
Bot
added
cranelift
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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 commit refactors the aarch64 backend to match the x64 backend with how it handles conditionals. Specifically there's now a "narrow waist" of a
CondResulttype which is used fortrapnz,trapz,select,icmp,brif, andselect_spectre_guard. This means that any lowering optimizations to handle conditionals are equally applied to all of these locations. Notably the smattering of optimizations and implementations across these instructions have all been deduplicated an unified. Codegen oftrap{n,}zis much better than before, and minor optimizations such as testing if an 8-bit value is 0 are now improved across the board. Finally, jumping after comparing a less-than-64-bit value now will use a 32-bit comparison instruction instead of a 64-bit comparison instruction, sometimes eliding the need to extend a 32-bit value to a 64-bit value.During this refactoring the method of comparing 128-bit integers was copied over from the x64 backend as well. This additionally significantly improves codegen over the previous iteration.
The end result is that it should be significantly easier to apply optimizations and bug fixes in the future. For example some float comparison orderings are not yet currently supported in the aarch64 backend, but are supported in the x64 backend, and this paves the way to make it much easier to add support for this feature as only one comparison-generation location need be updated and a small set of do-something-with-a-comparison locations will be specialized to the condition necessary.