-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
use noalias on the retptr parameter #9072
Labels
I-slow
Issue: Problems and improvements with respect to performance of generated code.
Comments
The |
thestinger
added a commit
that referenced
this issue
Sep 11, 2013
This brings Rust in line with how `clang` handles return pointers. Example: pub fn bar() -> [uint, .. 8] { let a = [0, .. 8]; a } Before: ; Function Attrs: nounwind uwtable define void @_ZN3bar17ha4635c6f704bfa334v0.0E([8 x i64]* nocapture, { i64, %tydesc*, i8*, i8*, i8 }* nocapture readnone) #1 { "function top level": %a = alloca [8 x i64], align 8 %2 = bitcast [8 x i64]* %a to i8* call void @llvm.memset.p0i8.i64(i8* %2, i8 0, i64 64, i32 8, i1 false) %3 = bitcast [8 x i64]* %0 to i8* call void @llvm.memcpy.p0i8.p0i8.i64(i8* %3, i8* %2, i64 64, i32 8, i1 false) ret void } After: ; Function Attrs: nounwind uwtable define void @_ZN3bar17ha4635c6f704bfa334v0.0E([8 x i64]* noalias nocapture sret, { i64, %tydesc*, i8*, i8*, i8 }* nocapture readnone) #1 { "function top level": %2 = bitcast [8 x i64]* %0 to i8* call void @llvm.memset.p0i8.i64(i8* %2, i8 0, i64 64, i32 8, i1 false) ret void } Closes #9072 Closes #7298
flip1995
pushed a commit
to flip1995/rust
that referenced
this issue
Aug 11, 2022
Move `significant_drop_in_scrutinee` into `nursey` The current suggestion of extending the lifetime of every sub-expression is not great and doesn't fix the error given in the lint's example, though it does make the potential deadlock easier to see, but it can also cause it's own issues by delaying the drop of the lock guard. e.g. ```rust match x.lock().foo { .. } // some stuff let y = x.lock(); ``` The suggestion would create a deadlock at the second `x.lock()` call. This also lints even when a significant drop type isn't created as a temporary. (rust-lang#9072) I agree `@kpreid` (rust-lang/rust-clippy#8987 (comment)) that this should be back-ported before the lint hits stable. changelog: Move `significant_drop_in_scrutinee` into `nursey`
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This is how
clang
handles it, but it also makes use ofsret
. I'm not sure if there would be any benefits from that.The text was updated successfully, but these errors were encountered: