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

always back ty::Const by an Allocation #58486

Closed
wants to merge 23 commits into from

Conversation

oli-obk
Copy link
Contributor

@oli-obk oli-obk commented Feb 15, 2019

This reduces the number of conversion between Allocation and Value by caching both.

r? @RalfJung

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Feb 15, 2019
@oli-obk oli-obk changed the title always back ty::Const ty an Allocation always back ty::Const by an Allocation Feb 15, 2019
@rust-highfive

This comment has been minimized.

@@ -2065,7 +2066,7 @@ pub enum LazyConst<'tcx> {
}

#[cfg(target_arch = "x86_64")]
static_assert!(LAZY_CONST_SIZE: ::std::mem::size_of::<LazyConst<'static>>() == 56);
static_assert!(LAZY_CONST_SIZE: ::std::mem::size_of::<LazyConst<'static>>() == 80);
Copy link
Member

Choose a reason for hiding this comment

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

And this isn't a problem? Let's do a perf run.

@oli-obk
Copy link
Contributor Author

oli-obk commented Feb 15, 2019

@bors try

@bors
Copy link
Contributor

bors commented Feb 15, 2019

⌛ Trying commit b0857a7 with merge dc96b91...

bors added a commit that referenced this pull request Feb 15, 2019
always back `ty::Const` by an `Allocation`

This reduces the number of conversion between `Allocation` and `Value` by caching both.

r? @RalfJung
@bors
Copy link
Contributor

bors commented Feb 15, 2019

☀️ Test successful - checks-travis
State: approved= try=True

@oli-obk
Copy link
Contributor Author

oli-obk commented Feb 15, 2019

@rust-timer build dc96b91

@rust-timer
Copy link
Collaborator

Success: Queued dc96b91 with parent f058741, comparison URL.

@rust-timer
Copy link
Collaborator

Finished benchmarking try commit dc96b91

@RalfJung
Copy link
Member

max-rss regressed noticeably, mostly for tuple-stress.

@@ -647,15 +646,15 @@ where
// does not permit code that would break this!
if self.alloc_map.contains_key(&alloc) {
// Not yet interned, so proceed recursively
self.intern_static(alloc, mutability)?;
let _alloc = self.intern_static(alloc, mutability)?;
Copy link
Member

Choose a reason for hiding this comment

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

Why bind this to an unused variable?

let field = ecx.mplace_field(down, field.index() as u64)?;
let val = match field.layout.abi {
layout::Abi::Scalar(..) => {
let scalar = ecx.try_read_immediate_from_mplace(field)?.unwrap().to_scalar()?;
Copy link
Member

Choose a reason for hiding this comment

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

Couldn't you use try_read_immediate(field.into())? Then we could avoid exposing that internal function try_read_immediate_from_mplace.

};
let ptr = Pointer::from(constant.alloc_id);
let alloc = constant.alloc;
Ok(ty::Const { val, ty: mplace.layout.ty, alloc: Some((alloc, ptr))})
Copy link
Member

Choose a reason for hiding this comment

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

The code above here is basically mplace_to_const, right? And we have the same in const_field, don't we? Couldn't that become a helper function?

})();
result.map_err(|error| {
let err = error_to_const_error(&ecx, error);
// FIXME(oli-obk): I believe this is unreachable and we can just ICE here. Since a constant
// is checked for validity before being in a place that could pass it to `const_field`,
// we can't possibly have errors. All fields have already been checked.
Copy link
Member

Choose a reason for hiding this comment

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

Could/should this FIXME be ported to the other PR?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'm trying this out locally in a different branch, so there's no reason to add it to the source tree

Centril added a commit to Centril/rust that referenced this pull request Feb 20, 2019
Centril added a commit to Centril/rust that referenced this pull request Feb 23, 2019
Centril added a commit to Centril/rust that referenced this pull request Feb 24, 2019
Centril added a commit to Centril/rust that referenced this pull request Feb 24, 2019
@bors
Copy link
Contributor

bors commented Feb 24, 2019

☔ The latest upstream changes (presumably #58691) made this pull request unmergeable. Please resolve the merge conflicts.

@RalfJung
Copy link
Member

I believe this got superseded by #58511 and can be closed?

@oli-obk oli-obk closed this Feb 25, 2019
@oli-obk oli-obk deleted the import_miri_from_future branch March 16, 2021 12:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants