hfinkel added a comment. In http://reviews.llvm.org/D17993#370790, @rjmccall wrote:
> Hal, I think you're talking about a slightly different thing. This patch is > adding an assumption that C++ this pointers are non-null, but only when > -fno-delete-null-pointer-checks is not passed. The flag is therefore at > least somewhat functional. (I would argue that it should also cover the > other cases where we add non-null assumptions, e.g. with reference arguments. > It's less clear whether it should change the code-generation of, say, > non-trivial l-value derived-to-base casts, where there's a null check that's > implicitly elided in the frontend.) We certainly can use a separate flag to control just this use of nonnull (and you're right, we should probably also have a corresponding way to turn off the nonnull reference assumptions). I'm just very afraid of incomplete implementations of -fno-delete-null-pointer-checks (seems like we're all on the same page about this now). > If you're saying that GCC's interpretation of this flag is more aggressive > than that — e.g. if it also changes how aggressively the optimizer will > decide that a pointer is non-null due to (say) it having been previously used > as a load/store argument, as in the infamous Linux kernel bug that GCC got > heat over — then I agree that we should probably avoid saying that we support > the attribute until we find a way to emulate that. That, I assume, would > have to be an attribute on the Function that weakens that analysis. Yes, this is my understanding, and I think a function attribute would be appropriate here. > I hope GCC's interpretation of this flag doesn't completely disable > null-check elimination, e.g. when the pointer is obviously the address of a > local or global variable. I don't know; but we should certainly find out. http://reviews.llvm.org/D17993 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
