Do not generate allocations for zero sized allocations #63635
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rust-highfive
added
the
S-waiting-on-review
|
Can you add a test, perhaps? Something that fails on master but passes with this change. |
eddyb
reviewed
Aug 16, 2019
src/librustc_codegen_llvm/common.rs
Outdated
| &self.const_usize(offset.bytes()), | ||
| 1, | ||
| )} | ||
| }; | ||
| let llval = self.const_bitcast(llval, self.type_ptr_to(layout.llvm_type(self))); |
There was a problem hiding this comment.
Could you move the bitcast to the non-zero-len arm? And compute this final pointer type only once?
eddyb
reviewed
Aug 16, 2019
src/librustc_codegen_llvm/common.rs
Outdated
| )}; | ||
| 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())) } |
There was a problem hiding this comment.
Also this seems like you're creating a i8** instead of i8* (but ideally we'd just go directly to the final type).
|
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()); |
|
Added tests and cleaned up the casting |
eddyb
approved these changes
Aug 18, 2019
|
@bors r+ |
|
📌 Commit 1ea88a8 has been approved by |
bors
added
S-waiting-on-bors
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
|
☀️ Test successful - checks-azure |
RalfJung
reviewed
Dec 13, 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); |
There was a problem hiding this comment.
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.
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
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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