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.

Sign up for GitHub

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

Jump to bottom

add a type-based alias analysis pass #6750

Closed
thestinger opened this issue May 26, 2013 · 2 comments
Closed

add a type-based alias analysis pass #6750

thestinger opened this issue May 26, 2013 · 2 comments
Labels
A-codegen Area: Code generation I-slow Issue: Problems and improvements with respect to performance of generated code.

Comments

@thestinger
Copy link
Contributor

We have an amazing amount of information that we're not passing along to LLVM. We should be attaching metadata to pointers and using it to respond to alias analysis queries. A good start would be to figure out how to make a shim responding MayAlias to all queries.

The NoAlias response may be used when there is never an immediate dependence between any memory reference based on one pointer and any memory reference based the other. The most obvious example is when the two pointers point to non-overlapping memory ranges. Another is when the two pointers are only ever used for reading memory. Another is when the memory is freed and reallocated between accesses through one pointer and accesses through the other — in this case, there is a dependence, but it’s mediated by the free and reallocation.

For Const objects, assuming no incorrect unsafe blocks, we can respond NoAlias for every &mut, & and ~ pointer because they either only read memory or are the only handle able to mutate the memory while they exist. We have the potential to beat C/C++ on a lot of benchmarks here...
@emberian
Copy link
Member

@smvv expressed interest in this.

@thestinger thestinger mentioned this issue May 4, 2014
Merged
bors added a commit that referenced this issue May 5, 2014
@bors
auto merge of #13935 : thestinger/rust/noalias, r=pcwalton
2be738a 
This was removed because these could alias with `&const T` or `@mut T`
and those are now gone from the language. There are still aliasing
issues within local scopes, but this is correct for function parameters.

This also removes the no-op `noalias` marker on proc (not a pointer) and
leaves out the mention of #6750 because real type-based alias analysis
is not within the scope of best effort usage of the `noalias` attribute.

Test case:

    pub fn foo(x: &mut &mut u32) {
        **x = 5;
        **x = 5;
    }

Before:

    define void @_ZN3foo20h0ce94c9671b0150bdaa4v0.0E(i32** nocapture readonly) unnamed_addr #0 {
    entry-block:
      %1 = load i32** %0, align 8
      store i32 5, i32* %1, align 4
      %2 = load i32** %0, align 8
      store i32 5, i32* %2, align 4
      ret void
    }

After:

    define void @_ZN3foo20h0ce94c9671b0150bdaa4v0.0E(i32** noalias nocapture readonly) unnamed_addr #0 {
    entry-block:
      %1 = load i32** %0, align 8
      store i32 5, i32* %1, align 4
      ret void
    }

Closes #12436
@thestinger
Copy link
Contributor Author

I don't think we need our own pass anymore. See #16515

flip1995 pushed a commit to flip1995/rust that referenced this issue Feb 25, 2021
@bors
Auto merge of rust-lang#6750 - flip1995:lintcheck_options, r=matthias…
ddeea97 
…krgr

Lintcheck and an options for command line options

Make it possible to add command line options to the clippy invocation of the lintcheck-tool

changelog: none

r? `@matthiaskrgr`

I found that this will be really helpful if we use a separate repository and want to maintain a all-lints-passing list of crates. See my early experimentation here: https://github.com/flip1995/clippy-lintcheck

```
git submodule update --init
cargo run -- --mode=all
```

Will run the lintcheck tool on all the specified crates in `config/` in that repository.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-codegen Area: Code generation I-slow Issue: Problems and improvements with respect to performance of generated code.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@emberian @thestinger