AVX128: Prescale addresses in gathers if possible #3825
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
If the host supports SVE128, if the address element size and data size is 64-bit, and the scale is not one of the two that is supported by SVE; Then prescale the addresses. 64-bit address overflow masks the top bits so is well defined that we can scale the vector elements and still execute the SVE code path in that case. Removing the ASIMD code paths from a lot of gathers. Fixes FEX-Emu#3805
Sonicadvance1
force-pushed
the
scale_64bit_gather
branch
from
0f1eab6 to
6e8ca3b
Compare
alyssarosenzweig
approved these changes
Jul 6, 2024
lioncash
approved these changes
Jul 6, 2024
Sonicadvance1
added a commit
to Sonicadvance1/FEX
that referenced
this pull request
Jul 6, 2024
When loading 256-bits of data with only 128-bits of address indices, we can sign extend the source indices to be 64-bit. Thus falling down the ideal path for SVE where each 128-bit lane is loading the data to addresses in a 1:1 element ratio. This means we use the SVE path more often because of this. Based on top of FEX-Emu#3825 because the prescaling behaviour was introduced there. This implements its own prescaling when the sign extension occurs because ARM's SSHLL{,2} instruction gives us that for free. This additionally fixes a bug where we were accidentally loading the top 128-bit half of the addresses for gathers when it was unnecessary, and on the AVX256 side it was duplicating and doing some additional work when it shouldn't have. It'll be good to walk the commits when looking at this one, as there are a couple of incremental changes that are easier to follow that way. Fixes FEX-Emu#3806
Sonicadvance1
added a commit
to Sonicadvance1/FEX
that referenced
this pull request
Jul 7, 2024
When loading 256-bits of data with only 128-bits of address indices, we can sign extend the source indices to be 64-bit. Thus falling down the ideal path for SVE where each 128-bit lane is loading the data to addresses in a 1:1 element ratio. This means we use the SVE path more often because of this. Based on top of FEX-Emu#3825 because the prescaling behaviour was introduced there. This implements its own prescaling when the sign extension occurs because ARM's SSHLL{,2} instruction gives us that for free. This additionally fixes a bug where we were accidentally loading the top 128-bit half of the addresses for gathers when it was unnecessary, and on the AVX256 side it was duplicating and doing some additional work when it shouldn't have. It'll be good to walk the commits when looking at this one, as there are a couple of incremental changes that are easier to follow that way. Fixes FEX-Emu#3806
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.
If the host supports SVE128, if the address element size and data size is 64-bit, and the scale is not one of the two that is supported by SVE; Then prescale the addresses.
64-bit address overflow masks the top bits so is well defined that we
can scale the vector elements and still execute the SVE code path in
that case. Removing the ASIMD code paths from a lot of gathers.
Fixes #3805
It's kind of cute that since the AVX256 implementation will fall back to the AVX128 implementation, that it naturally gains some of the uplift as well.