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

[George Burgess IV via llvm-dev]

Happy New Year ping. :)

Will ping again on Wednesday. If I don't get comments by EOD Thursday, I'll
assume everyone's OK with this and put together a patch.

On Wed, Dec 21, 2016 at 11:44 AM, George Burgess IV <
george.burgess.iv at gmail.com> wrote:

> 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/20170101/803feaa5/attachment.html>