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

Do not generate allocations for zero sized allocations #63635

Merged
merged 3 commits into from
Aug 18, 2019

Conversation

oli-obk
Copy link
Contributor

@oli-obk oli-obk commented Aug 16, 2019

Alternative to #62487

r? @eddyb

There are other places where we could do this, too, but that would cause static FOO: () = (); to not have a unique address

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Aug 16, 2019
@eddyb
Copy link
Member

eddyb commented Aug 16, 2019

Can you add a test, perhaps? Something that fails on master but passes with this change.

cc @scottmcm @nikomatsakis

&self.const_usize(offset.bytes()),
1,
)}
};
let llval = self.const_bitcast(llval, self.type_ptr_to(layout.llvm_type(self)));
Copy link
Member

Choose a reason for hiding this comment

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

Could you move the bitcast to the non-zero-len arm? And compute this final pointer type only once?

)};
let llval = if layout.size == Size::ZERO {
let llval = self.const_usize(alloc.align.bytes());
unsafe { llvm::LLVMConstIntToPtr(llval, self.type_ptr_to(self.type_i8p())) }
Copy link
Member

Choose a reason for hiding this comment

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

Also this seems like you're creating a i8** instead of i8* (but ideally we'd just go directly to the final type).

@scottmcm
Copy link
Member

Some easy, if indirect, tests:

    assert_eq!(<Vec<i32>>::new().as_ptr(), <&[i32]>::default().as_ptr());
    assert_eq!(<Box<[i32]>>::default().as_ptr(), (&[]).as_ptr());

@oli-obk
Copy link
Contributor Author

oli-obk commented Aug 17, 2019

Added tests and cleaned up the casting

@eddyb
Copy link
Member

eddyb commented Aug 18, 2019

@bors r+

@bors
Copy link
Contributor

bors commented Aug 18, 2019

📌 Commit 1ea88a8 has been approved by eddyb

@bors bors 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 Aug 18, 2019
Centril added a commit to Centril/rust that referenced this pull request Aug 18, 2019
Do not generate allocations for zero sized allocations

Alternative to rust-lang#62487

r? @eddyb

There are other places where we could do this, too, but that would cause `static FOO: () = ();` to not have a unique address
@bors
Copy link
Contributor

bors commented Aug 18, 2019

⌛ Testing commit 1ea88a8 with merge ea52be4...

bors added a commit that referenced this pull request Aug 18, 2019
Do not generate allocations for zero sized allocations

Alternative to #62487

r? @eddyb

There are other places where we could do this, too, but that would cause `static FOO: () = ();` to not have a unique address
@bors
Copy link
Contributor

bors commented Aug 18, 2019

☀️ Test successful - checks-azure
Approved by: eddyb
Pushing ea52be4 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Aug 18, 2019
@bors bors merged commit 1ea88a8 into rust-lang:master Aug 18, 2019
Comment on lines +9 to +12
let x: &'static () = &();
assert_eq!(x as *const () as usize, 1);
let x: &'static Foo = &Foo;
assert_eq!(x as *const Foo as usize, 4);
Copy link
Member

Choose a reason for hiding this comment

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

Does this constitute a stable guarantee that we will allocate ZSTs at certain addresses? I hope not, that seems quite arbitrary to me. After all we also don't guarantee where non-ZST are allocated.

@oli-obk oli-obk deleted the default-slice-dangles branch October 2, 2020 07:09
bors added a commit to rust-lang-ci/rust that referenced this pull request Apr 14, 2024
Codegen ZSTs without an allocation

This makes sure that &[] is equivalent to unsafe code (from_raw_parts(dangling, 0)). No new stable guarantee is intended about whether or not we do this, this is just an optimization.

This regressed in rust-lang#67000 (no comments I can see about that regression in the PR, though it did change the test modified here). We had previously performed this optimization since rust-lang#63635.
bors added a commit to rust-lang-ci/rust that referenced this pull request Apr 14, 2024
Codegen ZSTs without an allocation

This makes sure that &[] is equivalent to unsafe code (from_raw_parts(dangling, 0)). No new stable guarantee is intended about whether or not we do this, this is just an optimization.

This regressed in rust-lang#67000 (no comments I can see about that regression in the PR, though it did change the test modified here). We had previously performed this optimization since rust-lang#63635.
bors added a commit to rust-lang-ci/rust that referenced this pull request Apr 17, 2024
Codegen ZSTs without an allocation

This makes sure that &[] is equivalent to unsafe code (from_raw_parts(dangling, 0)). No new stable guarantee is intended about whether or not we do this, this is just an optimization.

This regressed in rust-lang#67000 (no comments I can see about that regression in the PR, though it did change the test modified here). We had previously performed this optimization since rust-lang#63635.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. 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.

6 participants