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

miri: use AllocId instead of u64. #47205

Merged
merged 1 commit into from
Jan 6, 2018
Merged

miri: use AllocId instead of u64. #47205

merged 1 commit into from
Jan 6, 2018

Conversation

eddyb
Copy link
Member

@eddyb eddyb commented Jan 5, 2018

This makes @alexreg's miri allocation -> LLVM global translation more straight-forward.

r? @oli-obk

@kennytm kennytm added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jan 5, 2018
@oli-obk
Copy link
Contributor

oli-obk commented Jan 5, 2018

Ha. That was on my list. Thanks for doing it. Lgtm

@eddyb
Copy link
Member Author

eddyb commented Jan 5, 2018

@bors delegate=oli-obk

@bors
Copy link
Contributor

bors commented Jan 5, 2018

✌️ @oli-obk can now approve this pull request

Copy link
Contributor

@oli-obk oli-obk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

let's readd the pointer once we implement the optimization

@bors r+

///
/// The pointers are to the beginning of an `alloc_by_id` allocation
alloc_cache: FxHashMap<interpret::GlobalId<'tcx>, interpret::Pointer>,
alloc_cache: FxHashMap<interpret::GlobalId<'tcx>, interpret::AllocId>,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The idea was that you could have globals which are located inside other locals in the future. So if a constant's value is obtained by indexing another constant, we'd just point to the offset in the array constant.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We do need miri allocations properly exposed for miri alloc -> LLVM global translation, or at least some guarantee that statics don't get optimized like that.
FWIW I think MemoryPointer would be a better fit, eventually.

@oli-obk
Copy link
Contributor

oli-obk commented Jan 5, 2018

@bors r+

Maybe bors doesn't like reviews?

@bors
Copy link
Contributor

bors commented Jan 5, 2018

📌 Commit 0907494 has been approved by oli-obk

@kennytm kennytm added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jan 6, 2018
kennytm added a commit to kennytm/rust that referenced this pull request Jan 6, 2018
miri: use AllocId instead of u64.

This makes @alexreg's miri allocation -> LLVM global translation more straight-forward.

r? @oli-obk
bors added a commit that referenced this pull request Jan 6, 2018
Rollup of 7 pull requests

- Successful merges: #46947, #47170, #47190, #47205, #47217, #47220, #47230
- Failed merges: #47233
@bors bors merged commit 0907494 into rust-lang:master Jan 6, 2018
@eddyb eddyb deleted the alloc-id branch January 6, 2018 23:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants