<div dir="ltr"><div>tl;dr: We'd like to add a bit to @llvm.objectsize to make it optionally be conservative when it's handed a null pointer.<br></div><div><div><br></div><div>Happy Wednesday!</div><div><br></div><div>We're trying to fix PR23277, which is a bug about how clang+LLVM treat __builtin_object_size when it's given a null pointer. For compatibility with GCC, clang would like to be able to hand back a conservative result (e.g. (size_t)-1), but the LLVM intrinsic that clang lowers __builtin_object_size(p, N) to, @llvm.objectsize, only hands back 0 when given a null pointer. Because it's often assumed that __builtin_object_size always folds to a constant, handling this only in clang may be tricky: if we emit the IR equivalent to ((p) ? __builtin_object_size(p, N) : -1ULL) and LLVM can't fold away the null check, we've failed to emit a constant.</div><div><br></div><div>So, the best path forward that I can see is to add a "null is unknown size" bit to @llvm.objectsize, much like the "min" bit it already has. If this bit is true, null would be treated like an opaque pointer. Otherwise, @llvm.objectsize would act no differently than it does today.</div></div><div><br></div><div>If we like this approach, I'm assuming it would be best to have this bit as a third argument to @llvm.objectsize, rather than making the second argument an i8 and using it as a bag of bits.</div><div><br></div><div>All thoughts/comments/alternative approaches/etc. highly appreciated. :)</div><div><br></div><div>Thanks (and Happy Holidays)!</div><div>George</div></div>