Skip to content

Mark &mut parameters as noalias #6742

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

Merged
merged 1 commit into from
May 26, 2013
Merged

Mark &mut parameters as noalias #6742

merged 1 commit into from
May 26, 2013

Conversation

Aatch
Copy link
Contributor

@Aatch Aatch commented May 26, 2013

This marks &mut function arguments with the noalias attribute. Since the borrow checker enforces this property, this is worth doing.

I'm not sure if the place I'm doing it in is ideal, but it generates the correct code.

Closes #6350

bors added a commit that referenced this pull request May 26, 2013
This marks `&mut` function arguments with the `noalias` attribute. Since the borrow checker enforces this property, this is worth doing.

I'm not sure if the place I'm doing it in is ideal, but it generates the correct code.

Closes #6350
@bors bors closed this May 26, 2013
@bors bors merged commit 2c2346e into rust-lang:incoming May 26, 2013
@brson
Copy link
Contributor

brson commented May 26, 2013

Do we actually know that all &mut parameters are no-alias? This seems pretty unlikely to me.

@thestinger
Copy link
Contributor

@brson: yes, LLVM's understanding of noalias is that it's the only way to mutate the value inside the scope and borrow checking provides this guarantee

You're allowed to have other references to the memory before and after the function, and the function can create more references to the value from the pointer it's passed.

Technically, & pointers are close to being noalias because LLVM regards 2 pointers as non-aliasing if neither of them is ever used to write to the destination. However, the fact that we have objects that are mutable without a mutable reference rules that out for now.

@brson
Copy link
Contributor

brson commented May 26, 2013

@thestinger If all Rust code was safe and obeyed borrow semantics then this would be true, but there is plenty of unsafe code that mutates immutable pointers. Do all those unsafe blocks preserve the assumption that &mut is unaliased? I don't know, but I doubt it.

@thestinger
Copy link
Contributor

@brson: I don't think we'll be able to do this for immutable pointers for a long time - but I doubt there's anything breaking the rules for &mut when it comes to function calls (we aren't marking any of the & references as noalias).

To break the rules, the function would need to have two borrowed pointer parameters with one or both being &mut, and the caller would have to pass the same for both. The result would be one of the pointers potentially not seeing a store done through the noalias pointer or vice versa.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants