zeroshade opened a new pull request, #37785:
URL: https://github.com/apache/arrow/pull/37785
<!--
Thanks for opening a pull request!
If this is your first pull request you can find detailed information on how
to contribute here:
* [New Contributor's
Guide](https://arrow.apache.org/docs/dev/developers/guide/step_by_step/pr_lifecycle.html#reviews-and-merge-of-the-pull-request)
* [Contributing
Overview](https://arrow.apache.org/docs/dev/developers/overview.html)
If this is not a [minor
PR](https://github.com/apache/arrow/blob/main/CONTRIBUTING.md#Minor-Fixes).
Could you open an issue for this pull request on GitHub?
https://github.com/apache/arrow/issues/new/choose
Opening GitHub issues ahead of time contributes to the
[Openness](http://theapacheway.com/open/#:~:text=Openness%20allows%20new%20users%20the,must%20happen%20in%20the%20open.)
of the Apache Arrow project.
Then could you also rename the pull request title in the following format?
GH-${GITHUB_ISSUE_ID}: [${COMPONENT}] ${SUMMARY}
or
MINOR: [${COMPONENT}] ${SUMMARY}
In the case of PARQUET issues on JIRA the title also supports:
PARQUET-${JIRA_ISSUE_ID}: [${COMPONENT}] ${SUMMARY}
-->
### Rationale for this change
The linked issue discovered a problem with the ARM64 implementation of the
extractBits functionality which was being hidden because until `go1.21`, it
looks like `golang.org/x/sys/cpu` wasn't properly detecting the ASIMD bit flag
on the ARM processors and so it was using the pure go implementation. So we fix
the assembly and add a test which was able to reproduce the failure without the
fix on an ARM64 machine.
<!--
Why are you proposing this change? If this is already explained clearly in
the issue then this section is not needed.
Explaining clearly why changes are proposed helps reviewers understand your
changes and offer better suggestions for fixes.
-->
### What changes are included in this PR?
There was a problem with the assembly as it existed as the short circuit
case where the selection bitmap is 0 wasn't actually setting the 0 value back
onto the stack as a return. The assembly which initialized that register to 0
only occurred AFTER the `CBZ` instruction which would jump to the bottom and
return. This means that we *actually* returned whatever happened to be on the
stack at that location (i.e. garbage!). This only occurred if you were using
the ARM64-specific assembly implementation, not the amd64 or pure go versions.
We also include a test to ensure we get the correct values for a variety of
bitmaps and selections, along with this ensuring there's enough data on the
stack so that if this problem re-occured we would catch it in this test.
### Are these changes tested?
Test is added.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
