[PATCH] D130107: MemoryBuiltins: remove malloc-family funcs from list

Augie Fackler via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Jul 28 07:09:31 PDT 2022


durin42 added a comment.

In D130107#3684978 <https://reviews.llvm.org/D130107#3684978>, @qiongsiwu1 wrote:

> May I ask for some guidance/example on how to use the attributes to identify that the removed functions (e.g. `malloc, calloc, realloc`) are still allocation functions?
>
> Is it true that `bool llvm::isAllocationFn` returns `false` now if the input is a `malloc` call? It seems to be so in my experiments. Is this intended? This is contradictory to the code comment <https://github.com/llvm/llvm-project/blob/bd08f413c089da5a56438cc8902f60df91a08a66/llvm/lib/Analysis/MemoryBuiltins.cpp#L293> .

If the function isn't annotated with the right attributes, it won't be understood to be an allocation function unless it's in the big static list in MemoryBuiltins. There were a series of changes to BuildLibCalls (eg D123089 <https://reviews.llvm.org/D123089>) which mean that the -inferattrs pass will insert the right attributes on your function declarations, so you may just need an extra pass for that to work, or to add the attributes manually in your test case if you don't want to run attribute inference.

> Additionally, what is the recommended approach now to tell if a library function allocates memory? It seems that `bool llvm::isAllocationFn` is covering //some// functions (ones still included in the list  `AllocationFnData`), but not others (ones this patch removed). When should we use `bool llvm::isAllocationFn`? Or should we migrate to use attributes and avoid using `bool llvm::isAllocationFn`?

I'd still use isAllocationFn - that checks both the static list and the attributes. If we ever manage to get the list to empty, that should still work.

Does that help?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D130107/new/

https://reviews.llvm.org/D130107



More information about the llvm-commits mailing list