[llvm-dev] RFC: Allowing @llvm.objectsize to be more conservative with null.
George Burgess IV via llvm-dev
llvm-dev at lists.llvm.org
Sun Jan 1 22:03:28 PST 2017
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)!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev