diff options
| author | Patrick Walton <pcwalton@fb.com> | 2022-10-26 15:12:19 -0700 |
|---|---|---|
| committer | Erik Desjardins <erikdesjardins@users.noreply.github.com> | 2023-05-20 18:12:53 -0400 |
| commit | f71741bac41a5373791958d4a0a36c84d83b1bd5 (patch) | |
| tree | 762bbc4bb5d452de51ebcb77b96cc251f6ec40dc /compiler/rustc_mir_transform/src/coverage/debug.rs | |
| parent | e77366b57b799dfa3ce1fcb850c068723a3213ee (diff) | |
| download | rust-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
