zeroshade commented on code in PR #37785:
URL: https://github.com/apache/arrow/pull/37785#discussion_r1331777665
##########
go/parquet/internal/bmi/bitmap_neon_arm64.s:
##########
@@ -27,8 +27,8 @@ LBB0_2:
MOVD R0, res+16(FP)
RET
LBB0_4:
- WORD $0xaa1f03e0 // mov x0, xzr
WORD $0xa8c17bfd // ldp x29, x30, [sp], #16
+ MOVD ZR, res+16(FP)
Review Comment:
The assembly wasn't *generated* by hand, but this fix was absolutely written
by hand (me) by way of looking at the code, the generated assembly, and
stepping through the instructions to figure out what was happening incorrectly.
In this case, the problem was that the instructions which zero-out the
return value got placed *after* the loop condition (checking if the selection
bitmap was zero), so in that scenario we ended up returning whatever happened
to be the next 8 bytes after the memory location the arguments were placed. I
had to look up a bunch of stuff about how Go plan9 assembly works and also
ARM64 assembly, to work out that zero'ing out one area was able to be done by
simply storing from `ZR` the zero-register.
--
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]