[PATCH] D47895: llvm: Add support for "-fno-delete-null-pointer-checks"

Manoj Gupta via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Jul 25 12:50:22 PDT 2018


manojgupta added a comment.

In https://reviews.llvm.org/D47895#1175164, @a.elovikov wrote:

> > Note that, I am expecting that functions with alwaysinline attribute should still get inlined. If that happens and caller does not have this attribute, then optimizer is free to remove the checks.
>
> Not that I actually hit that, but it was questionable when reading the code - why that way? From LangRef: alwaysinline "indicates that the inliner should attempt to inline this function into callers whenever possible, ignoring any active inlining size threshold for this caller." So there is some freedom by not doing the inlining, even in the presence of the attribute.
>
> Wouldn't it be better not to inline or to add the attribute to the caller?


Thanks for the comments.

Generally clang should add the attribute to all the  functions if "-fno-delete-null-pointer-checks" is used so the mismatch should not happen in practice.

As per my understanding, If the "null-pointer-is-valid" is missing on a caller (but present on callee), this probably would happen in LTO where caller was intentionally compiled without  "-fno-delete-null-pointer-checks".  So adding the attribute to caller is probably not desired.
It was not clear to me if "-fno-delete-null-pointer-checks" mismatch should override always_inline but my inclination was to honor the user/system specified attribute over the compiler option.

I would be happy to change this logic if there is a consensus on how inlining should be handled in case of  "null-pointer-isvalid" attribute mismatches.


Repository:
  rL LLVM

https://reviews.llvm.org/D47895





More information about the llvm-commits mailing list