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

[Philip Reames via llvm-dev]

On 1/6/22 7:45 AM, Augie Fackler via llvm-dev wrote:
>
>
> On Wed, Jan 5, 2022 at 7:58 PM Jessica Clarke <jrtc27 at jrtc27.com 
> <mailto:jrtc27 at jrtc27.com>> wrote:
>
>     On 5 Jan 2022, at 22:32, Augie Fackler via llvm-dev
>     <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>     > Proposal
>     > =======
>     > We add two attributes to LLVM IR:
>     >
>     >  * `allocator(FAMILY)`: Marks a function as part of an allocator
>     family, named by the “primary” allocation function (e.g.
>     `allocator(“malloc”)`, `allocator(“_Znwm”)`, or
>     `allocator(“__rust_alloc”)`).
>
>     Why do you need a family? What’s insufficient about just using
>     allocsize(idx), as used by __attribute__((alloc_size(...)) in GNU
>     C? (Which you acknowledge the existence of, but don’t justify why
>     you need your own attribute.) What to use as the allocator
>     “family” string for C++ operator new seems pretty unclear too, so
>     I’m not sure how good an idea this free-form string argument is in
>     your proposal.
>
>
> For C++ new we'd use the mangled form of ::operator::new, aka _Znwm. 
> The reason for the family is so that we can track which allocations 
> are related, so that incorrect code like
>
> {
>   auto *foo = new Foo();
>   free(foo);
> }
>
> doesn't get optimized away. I believe others I talked to while 
> designing this might have had more interesting ideas for how the 
> family could be used, but it's easy to put in today, and roughly 
> impossible to add via an IR upgrade if we don't put it in, so it seems 
> sensible to try and track the family now. I actually initially argued 
> against the family argument, but was won over by the limitation that 
> we'd be unable to upgrade it in the future.
JFYI, this example does not provide the motivation you seem to think it 
does.  This example is to my knowledge, immediate UB.  As such, there's 
no need to "avoid" the optimization.  If anything, we should be more 
aggressive and convert this to an unreachable.
>
>     >  * `releaseptr(idx)`: Indicates that the function releases the
>     pointer that is its Nth argument.
>
>     This should probably just be free(idx)/frees(idx)/willfree(idx)
>     (we already have nofree as an attribute for arguments), or an
>     attribute on the argument itself. Talking about releasing makes it
>     sound like reference counting semantics.
>
>
> Sure, that seems reasonable. I'll update my prototype to use that name 
> instead. Thanks!
>
>
>     Jess
>
>
> _______________________________________________
> 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/20220106/a9103744/attachment.html>