[PATCH] D17993: [CodeGen] Apply 'nonnull' to 'this' pointer arguments.

[Hal Finkel via cfe-commits]

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