-
Notifications
You must be signed in to change notification settings - Fork 13.1k
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
use information about non-raw pointers being non-null #9546
Comments
LLVM already has some optimization support for pointers that are known not to be null. Unfortunately as far as function arguments are concerned, that only covers those with the
|
An attribute won't really be enough, because the information is lost after inlining. |
Do you have an example where the information is needed after inlining (or more generally, where the information is useful for a pointer that is neither an argument to the function nor is it dereferenced)? |
@dotdash: #11751 is an example where the information is likely lost during inlining. The |
With #14306 we get better in some cases: #[no_mangle]
pub fn foo(x: &int) -> bool {
Some(x) == None
}
; Function Attrs: nounwind readonly uwtable
define i8 @foo(i64* nocapture nonnull) unnamed_addr #0 {
"_ZN6option30Option$LT$T$GT$...std..cmp..Eq2eq21h172342516211389848784v0.0E.exit":
ret i8 0
} |
I believe this issue should be closed. It's vague, and despite this vagueness addressed as much as we can hope to without fundamentally altering LLVM:
I'll also point out that non-nullness of references is a special case of communicating invalid values to LLVM. For example, that references are always aligned or that |
…Frednet [`should_implement_trait`] Also lint `default` method close rust-lang/rust-clippy#8550 changelog: FP: [`should_implement_trait`]: Now also works for `default` methods
We can set this in arbitrary metadata, and then write an LLVM pass to consume it and mark them as non-null.
This is awful:
The text was updated successfully, but these errors were encountered: