Skip to content

mark unique pointer parameters as noalias #6754

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

Closed
wants to merge 1 commit into from
Closed

mark unique pointer parameters as noalias #6754

wants to merge 1 commit into from

Conversation

thestinger
Copy link
Contributor

The compiler guarantees that there are no other references to a unique pointer when it's passed by-value to a function.

The existence of the header and annihilator don't matter since it's not relevant to the call:

For a call to the parent function, dependencies between memory references from before or after the call and from those during the call are “irrelevant” to the noalias keyword for the arguments and return value used in that call.

@graydon's tracing garbage collector stores the metadata outside of the boxes, so that won't be a problem. I'm unsure if updating the header while inside a function where it's marked as noalias would be a problem anyway since you never actually read or write to the header.

@nikomatsakis: r?

@Aatch
Copy link
Contributor

Aatch commented May 27, 2013

As far as I'm aware, noalias just means that the two pointers don't directly point to overlapping ranges. Since you can imagine the fields of a struct as individual unique pointers within a "top-level" unique pointer, you couldn't get an overlapping range, since there would then be multiple pointers to the same data. The same logic applies to vectors/arrays.

Finally, noalias only really matters if you are doing something that is affected by potential aliasing, I'm not too familiar with the scope of LLVM's inter-procedural optimization but short of deliberately constructing a pair of aliasing unique pointers, I'm having a hard time imagining a case that might cause LLVM to perform an invalid optimization.

bors added a commit that referenced this pull request May 28, 2013
The compiler guarantees that there are no other references to a unique pointer when it's passed by-value to a function.

The existence of the header and annihilator don't matter since it's not relevant to the call:

> For a call to the parent function, dependencies between memory references from before or after the call and from those during the call are “irrelevant” to the noalias keyword for the arguments and return value used in that call.

@graydon's tracing garbage collector stores the metadata outside of the boxes, so that won't be a problem. I'm unsure if updating the header while inside a function where it's marked as `noalias` would be a problem anyway since you never actually read or write to the header.

@nikomatsakis: r?
@bors bors closed this May 28, 2013
flip1995 pushed a commit to flip1995/rust that referenced this pull request Feb 25, 2021
Teach SpanlessEq binding IDs

changelog: Fix collapsible_match false positive

Fixes rust-lang#6740

This PR changes the way `SpanlessEq` determines whether two local variables are the same. Instead of checking that the names match, it checks that the `HirId`s match. If local bindings are declared within the expressions that are being compared, `SpanlessEq` will remember bindings that correspond to each other in a `FxHashMap<HirId, HirId>`. This makes `SpanlessEq` more flexible while also fixing false positives.

Example: `{ let x = 1; x + 2 }` is equal to `{ let y = 1; y + 2 }`.

CC `@xFrednet` I think this will resolve some concerns in rust-lang#6463
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.

3 participants