-
Notifications
You must be signed in to change notification settings - Fork 13k
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
Add a flat address space to librustc_codegen_llvm
#62565
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @cramertj (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
r? @eddyb |
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
Changes to |
There's a merge commit that shouldn't exist - you might need to rebase. |
This seems to contain #51576, which was never shrunk enough for inclusion. |
67b23c3
to
c7b5154
Compare
Last night I was panicking that everything wasn't working because I've crashed miserably with the While reviewing the code locally I've seen a lot of the code problems pointed out by @eddyb, like a few lines we could change. I've left them untouched 'cause I wanted to see if the PR itself could work with Edit: I'll add the tests in the |
Ping from triage, any updates? @eddyb |
@Alexendoo Sorry, this was incorrectly tagged. |
☔ The latest upstream changes (presumably #62961) made this pull request unmergeable. Please resolve the merge conflicts. |
@eddyb they have pushed a new commit. You can review it now. |
☔ The latest upstream changes (presumably #63074) made this pull request unmergeable. Please resolve the merge conflicts. |
@eddyb the conflicts are now solved, you can review this freely 👓 ✏️ |
Hey! This is a ping from triage, we would like to know if you @eddyb could give us a few more minutes to update us from last changes made by @YakoYakoYokuYoku . Thanks. |
assert!(!layout.is_unsized(), "tried to statically allocate unsized place"); | ||
let tmp = bx.alloca(bx.cx().backend_type(layout), name, layout.align.abi); | ||
Self::new_sized(tmp, layout, layout.align.abi) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is identical to alloca
above though?
@@ -292,7 +293,8 @@ impl<'a, 'tcx, Bx: BuilderMethods<'a, 'tcx>> FunctionCx<'a, 'tcx, Bx> { | |||
bx.load(addr, self.fn_ty.ret.layout.align.abi) | |||
} | |||
}; | |||
bx.ret(llval); | |||
let llvalc = bx.flat_addr_cast(llval); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO the only way this PR will be accepted without an RFC is if everything is cast to the flat address space as soon as possible (as opposed to when needed).
} | ||
fn type_ptr_to_mut(&self, ty: Self::Type) -> Self::Type { | ||
self.type_as_ptr_to(ty, self.mutable_addr_space()) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These methods shouldn't be added if they're unused.
} | ||
|
||
pub fn val_addr_space(v: &'ll Value) -> AddrSpaceIdx { | ||
val_addr_space_opt(v).unwrap_or_default() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reflecting LLVM values should be avoided as much as possible. New uses of val_ty
shouldn't be added.
Ping from triage. @YakoYakoYokuYoku any updates on this? Thanks @rustbot modify labels to +S-waiting-on-author, -S-waiting-on-review |
Think It's better to prepare a proper RFC, closing this. |
To achieve compatibility with LLVM target machines which place allocas in another address space we need to the presence of a flat address space (an address space that is shared with other address spaces).
Also this PR updates #51576.