Skip to content
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

Closed
thestinger opened this issue Sep 9, 2013 · 1 comment
Closed

use noalias on the retptr parameter #9072

thestinger opened this issue Sep 9, 2013 · 1 comment
Labels
I-slow Issue: Problems and improvements with respect to performance of generated code.

Comments

@thestinger
Copy link
Contributor

This is how clang handles it, but it also makes use of sret. I'm not sure if there would be any benefits from that.

@thestinger
Copy link
Contributor Author

The memcpyopt pass takes advantage of sret so that's a good enough reason to use it.

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
Labels
I-slow Issue: Problems and improvements with respect to performance of generated code.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant