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

Hi all,

It's quite a coincidence to see this proposal. I just joined this list a few
days ago specifically to ask about the correct way to annotate allocation and
freeing functions. I'll create a separate thread to ask questions about my
specific situation but I wanted to add my support for this proposal here.

My main question is if there should be some way to specify the kind of
allocation function. In the hardcoded AllocationFnData array, there is a field
to specify if the function acts like malloc, new, calloc, realloc, etc. This
could be added to the annotation but I think a better way would be to specify
the actual properties of interest. Can it return null, does it align the
allocation, and what are the values in the newly allocated space (undef for
malloc, 0 for calloc, something unknown but defined for strdup). This would also
allow for creating new types of allocators that don't already exist.

I've created a patch with what this might look like for the existing
hardcoded functions here: https://reviews.llvm.org/D116797
<https://reviews.llvm.org/D116797>. In my initial implementation, I
realized that there are a lot of places where argument positions are hardcoded
and special detection of strdup and strndup is hardcoded. Regardless of if we
add the ability to specify these properties in attribute form or not, we will at
least need to ensure that the correct arguments are used based on an allocsize
annotation if available.

Sincerely,
Bryce Michael Wilson

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

On 1/7/22 1:23 AM, Bryce Wilson via llvm-dev wrote:
> Hi all,
>
> It's quite a coincidence to see this proposal. I just joined this list 
> a few days ago specifically to ask about the correct way to annotate 
> allocation and freeing functions. I'll create a separate thread to 
> ask questions about my specific situation but I wanted to add my 
> support for this proposal here.
>
> My main question is if there should be some way to specify the kind of 
> allocation function. In the hardcoded AllocationFnData array, there is 
> a field to specify if the function acts like malloc, new, calloc, 
> realloc, etc. This could be added to the annotation but I think 
> a better way would be to specify the actual properties of interest. 
> Can it return null, does it align the allocation, and what are the 
> values in the newly allocated space (undef for malloc, 0 for calloc, 
> something unknown but defined for strdup). This would also allow for 
> creating new types of allocators that don't already exist.
Bryce, I completely agree with this property based approach.  In fact, 
I've spent the last day or so landing patches which move us in exactly 
that direction.  Unfortunately, I think a good amount of your patch is 
now redundant, but if you wanted to swap notes on remaining things to 
fix, please feel free to ping me directly. I'll also start adding you on 
reviews where appropriate.

One subtle but important point: we do not want to have any property of 
an allocation function which can be expressed with existing attributes.  
So, for instance, we do not want code to be dependent on throwing 
operator new never returning null.  Instead, we want said functions 
annotated nonnull, and the generic code to drive the optimization.
>
> I've created a patch with what this might look like for the existing 
> hardcoded functions here: https://reviews.llvm.org/D116797 
> <https://reviews.llvm.org/D116797>. In my initial implementation, I 
> realized that there are a lot of places where argument positions are 
> hardcoded and special detection of strdup and strndup is hardcoded. 
> Regardless of if we add the ability to specify these properties in 
> attribute form or not, we will at least need to ensure that the 
> correct arguments are used based on an allocsize annotation if available.
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.
>
> Sincerely,
> Bryce Michael Wilson
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20220107/2426c5be/attachment.html>