[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