-
Notifications
You must be signed in to change notification settings - Fork 69
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 StatementKind::Intrinsic to MIR #348
Comments
This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed. |
Also see: |
Is this missing a negation? |
ah yes, yes it is |
@rustbot second |
@rustbot third I’m willing to review changes that implement this too, so do r? me on implementation PRs as well. |
Additionally, these intrinsics must also be known to always return (i.e., they must never cause an infinite loop). |
Add StatementKind::CopyNonOverlapping Implements rust-lang/compiler-team#348 r? `@nagisa`
Add StatementKind::CopyNonOverlapping Implements rust-lang/compiler-team#348 r? `@nagisa`
Proposal
Extend Mir to include statements for specific intrinsic function calls that are known to not panic or unwind under any conditions. Currently, function calls can only be used in terminator position, but permitting intrinsics which have better known behaviour to be interspersed will make it easier to create optimizations in the future.
Create a specialized terminator for the optimization of certain intrinsics. Specifically, proposing
StatementKind::CopyNonOverlapping
since memcpy is a function we often want to optimize over. The structure of the statement for this intrinsic would beStatementKind::CopyNonOverlapping { src: Box<Place<'tcx>>, dst: Box<Place<'tcx>>, size: Operand }
. This would be easy enough to convert in the future to a nestedStatementKind::Intrinsic
operator if more additions are added.Mentors or Reviewers
@oli-obk
Process
The main points of the Major Change Process is as follows:
@rustbot second
.-C flag
, then full team check-off is required.@rfcbot fcp merge
on either the MCP or the PR.You can read more about Major Change Proposals on forge.
Comments
This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.
The text was updated successfully, but these errors were encountered: