-
Notifications
You must be signed in to change notification settings - Fork 18k
runtime: memmove executes unaligned accesses on riscv64 #48248
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Change https://golang.org/cl/348393 mentions this issue: |
Unfortunately I think this needs to wait for the next release at this point. |
cc @golang/riscv64 |
This CL still in "merge conflicted" cc @mundaym Could you take a look? Thanks. |
Change https://go.dev/cl/426256 mentions this issue: |
Someone just tripped over this bug over on golang-dev. They are probably using 1.19 and thus didn't pick up the fix for this bug, but worth watching just in case: |
The performance of memmove when copying more than ~16 bytes of unaligned data is very poor on the HiFive Unmatched. Looking at the code it only attempts to align the source operand before using word-sized load and store operations. This means that stores to the destination operand will be unaligned. On the HiFive Unmatched unaligned accesses result in a trap that is handled by the kernel and so performance is extremely poor (~10x slower than performing a byte-by-byte copy).
Benchmarks:
The text was updated successfully, but these errors were encountered: