[PATCH] D14933: Add the allocsize attribute to LLVM
Ahmed Bougacha via llvm-commits
llvm-commits at lists.llvm.org
Tue Feb 16 20:49:09 PST 2016
ab added a comment.
Before going further:
> Honestly, and this is me speaking from a position of complete ignorance as to what the actual real-life use case of this would be, in what case are tiny wrapper functions unacceptable? The only things I have to pull from are here: http://lists.llvm.org/pipermail/cfe-dev/2012-June/022272.html -- can you tell me why the below alternatives don't work just as well? Or give me an example where it wouldn't be possible to write a similar wrapper? I'm unable to think of one.
FWIW, I agree. One could justify the expression support as simplifying the transition for users (the alternative you show does require manual work), but I think this attribute is enough.
That said, the expression support (http://reviews.llvm.org/D16390) is an interesting thought experiment (Disclaimer: just a curious bystander). So, I was thinking you'd IRGen the whole expression at every callsite; and this is what I meant with "wrapping" the calls:
define i8* @checked_malloc(i32 %N) {
%p = call i8* @object_malloc(i32 %N)
%size = add i32 %N, 8
%1 = call i8* @llvm.assume_alloc_size_and_offset.p0i8(i8* %p, i32 %size, i32 -8)
%2 = call i32 @llvm.objectsize.i32.p0i8(i8* %1)
%3 = icmp lt %2, %N
br i1 %3, label %Trap, label %Return
...
}
I think this avoids all problems except:
> - `@__autogenerated_get_object_size_of_object_malloc` isn't allowed to have any side-effects (because the intrinsic would presumably be treated as though it has no side-effects, much unlike a `call` instruction).
> - We need to keep around anything passed to `@__autogenerated_get_object_size_of_object_malloc` until the intrinsic is deleted, so it may suffer from similar optimization problems as `@llvm.assume`.
> - We still need to emit this at every callsite to any allocation function.
Also, +1 to Sanjoy's operand bundles approach: I think it's equivalent but cleaner. (Same caveat applies.)
http://reviews.llvm.org/D14933
More information about the llvm-commits
mailing list