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]

Reply via email to