-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Support memcpy/memmove with differing src/dst alignment #55633
Conversation
r? @estebank (rust_highfive has picked a reviewer for you, use r? to override) |
This comment has been minimized.
This comment has been minimized.
let volatile = C_bool(cx, flags.contains(MemFlags::VOLATILE)); | ||
bx.call(memcpy, &[dst_ptr, src_ptr, size, align, volatile], None); | ||
let volatile = flags.contains(MemFlags::VOLATILE); | ||
bx.memcpy(dst_ptr, dst_align.abi(), src_ptr, src_align.abi(), size, volatile); | ||
} | ||
|
||
pub fn memcpy_ty( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the benefit of allowing caller to specify different src
layout and src
alignment (contained within their respective layout
) separately?
Seeing it is a convenience wrapper, it would make sense to simply take TyLayout
for both dst
and src
and extract the necessary information from that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think those alignments necessarily match. A type can be stored at a location with higher alignment than what the type layout alignment specifies. One example where this may happen is for field projections, where the alignment of the field is determined by the alignment of the containing structure and the field offset, not the layout alignment of the field type.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One example where this may happen is for field projections, where the alignment of the field is determined by the alignment of the containing structure and the field offset, not the layout alignment of the field type.
Fair. Although we don’t optimise this way currently, there were some discussion about doing so, so code might end up becoming what it looks like now anyway.
@bors r+ |
📌 Commit bea6b93673df3756961e2c6e3cf10df0a5aa26e8 has been approved by |
☔ The latest upstream changes (presumably #55238) made this pull request unmergeable. Please resolve the merge conflicts. |
r? @nagisa |
@bors r+ |
📌 Commit a470395e58833f2536403e2c4ee12d7b49809739 has been approved by |
☔ The latest upstream changes (presumably #55349) made this pull request unmergeable. Please resolve the merge conflicts. |
If LLVM 7 is used, generate memcpy/memmove with differing src/dst alignment. I've added new FFI functions to construct these through the builder API, which is more convenient than dealing with differing intrinsic signatures depending on the LLVM version.
Rebased |
@bors r+ |
📌 Commit 463ad90 has been approved by |
Support memcpy/memmove with differing src/dst alignment If LLVM 7 is used, generate memcpy/memmove with differing src/dst alignment. I've added new FFI functions to construct these through the builder API, which is more convenient than dealing with differing intrinsic signatures depending on the LLVM version. Fixes #49740.
💔 Test failed - status-appveyor |
Three hour timeout on one job, everything else passed. Probably spurious. |
@bors: retry delegate+ |
✌️ @nikic can now approve this pull request |
Support memcpy/memmove with differing src/dst alignment If LLVM 7 is used, generate memcpy/memmove with differing src/dst alignment. I've added new FFI functions to construct these through the builder API, which is more convenient than dealing with differing intrinsic signatures depending on the LLVM version. Fixes rust-lang#49740.
Rollup of 17 pull requests Successful merges: - #55576 (Clarify error message for -C opt-level) - #55633 (Support memcpy/memmove with differing src/dst alignment) - #55638 (Fix ICE in msg_span_from_free_region on ReEmpty) - #55659 (rustc: Delete grouping logic from the musl target) - #55719 (Sidestep link error from rustfix'ed code by using a *defined* static.) - #55736 (Elide anon lifetimes in conflicting impl note) - #55739 (Consume optimization fuel from the MIR inliner) - #55742 (Avoid panic when matching function call) - #55753 (borrow_set: remove a helper function and a clone it uses) - #55755 (Improve creation of 3 IndexVecs) - #55758 ([regression - rust2018]: unused_mut lint false positives on nightly) - #55760 (Remove intermediate font specs) - #55761 (mir: remove a hacky recursive helper function) - #55774 (wasm32-unknown-emscripten expects the rust_eh_personality symbol) - #55777 (Use `Lit` rather than `P<Lit>` in `ast::ExprKind`.) - #55783 (Deprecate mpsc channel selection) - #55788 (rustc: Request ansi colors if stderr isn't a tty) Failed merges: r? @ghost
If LLVM 7 is used, generate memcpy/memmove with differing src/dst alignment. I've added new FFI functions to construct these through the builder API, which is more convenient than dealing with differing intrinsic signatures depending on the LLVM version.
Fixes #49740.