about summary refs log tree commit diff
path: root/compiler/rustc_mir_transform/src/coverage/debug.rs
diff options
context:
space:
mode:
authorPatrick Walton <pcwalton@fb.com>2022-10-26 15:12:19 -0700
committerErik Desjardins <erikdesjardins@users.noreply.github.com>2023-05-20 18:12:53 -0400
commitf71741bac41a5373791958d4a0a36c84d83b1bd5 (patch)
tree762bbc4bb5d452de51ebcb77b96cc251f6ec40dc /compiler/rustc_mir_transform/src/coverage/debug.rs
parente77366b57b799dfa3ce1fcb850c068723a3213ee (diff)
downloadrust-f71741bac41a5373791958d4a0a36c84d83b1bd5.tar.gz
rust-f71741bac41a5373791958d4a0a36c84d83b1bd5.zip
[rustc_ty_utils] Add the LLVM `noalias` parameter attribute to `drop_in_place` in certain cases.
LLVM can make use of the `noalias` parameter attribute on the parameter to
`drop_in_place` in areas like argument promotion. Because the Rust compiler
fully controls the code for `drop_in_place`, it can soundly deduce parameter
attributes on it. In the case of a value that has a programmer-defined Drop
implementation, we know that the first thing `drop_in_place` will do is pass a
pointer to the object to `Drop::drop`. `Drop::drop` takes `&mut`, so it must be
guaranteed that there are no pointers to the object upon entering that
function. Therefore, it should be safe to mark `noalias` there.

With this patch, we mark `noalias` only when the type is a value with a
programmer-defined Drop implementation. This is possibly overly conservative,
but I thought that proceeding cautiously was best in this instance.
Diffstat (limited to 'compiler/rustc_mir_transform/src/coverage/debug.rs')
0 files changed, 0 insertions, 0 deletions