[llvm-dev] [RFC] Adding support for marking allocator functions in LLVM IR

[Philip Reames via llvm-dev]

On 1/7/22 1:55 PM, James Y Knight wrote:
>
>
> On Fri, Jan 7, 2022 at 4:48 PM Philip Reames via llvm-dev 
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>
>     I think I've already killed several of the ones you note.  I agree
>     there's definite room to improve the handling of strdup/strndup. 
>     If you wanted to write a patch for that specifically, I'd be happy
>     to review.
>
> IMO, it doesn't seem worthwhile to make strdup handling expressible 
> with generic attributes. We special case many other libc functions 
> too, so this is not unusual, and unlike other allocator properties, 
> "strdup-like" does not seem likely to be a very interesting thing to 
> apply to other functions.
>
Er, I was apparently unclear.

The sole remaining property of a strndup that we can't get from generic 
attributes (which already exist) is the clamp on result size.  We can 
entirely remove strdup special casing (by having either the frontend or 
BuildLibCalls annotate it with appropriate attributes.)  We can *almost* 
do the same for strndup minus the size special casing.

So, we can remove a bunch of existing special case code.  We would not 
be adding any new attribute motivated by strdup.  I agree it appears to 
be an uncommon pattern.

One potential interaction I've not looked at is the nobuiltin bit, but 
presumably we must have already solved that as we're adding attributes 
to lots of other libfuncs.

Do drive this through, we do need to switch a bunch of transforms from 
isAllocLike to noalias return driven as well.  (I'm assuming we want to 
do that for all kinds of reasons.)

Philip

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20220107/8f4f7a6e/attachment.html>