[llvm-dev] RFC: Allowing @llvm.objectsize to be more conservative with null.

George Burgess IV via llvm-dev llvm-dev at lists.llvm.org
Wed Dec 21 11:44:09 PST 2016


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.

Happy Wednesday!

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.

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.

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.

All thoughts/comments/alternative approaches/etc. highly appreciated. :)

Thanks (and Happy Holidays)!
George
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161221/d68f9c6b/attachment.html>


More information about the llvm-dev mailing list