rjmccall added a comment.

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.)

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.

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.


================
Comment at: include/clang/Driver/Options.td:1157
@@ -1154,1 +1156,3 @@
+def fno_delete_null_pointer_checks : Flag<["-"], 
"fno-delete-null-pointer-checks">,
+  Group<f_clang_Group>, Flags<[CC1Option]>;
 
----------------
Please include HelpText, and it's probably worth talking about this in the 
actual docs.


http://reviews.llvm.org/D17993



_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to