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

[Augie Fackler via llvm-dev]

On Wed, Jan 5, 2022 at 7:58 PM Jessica Clarke <jrtc27 at jrtc27.com> wrote:

> On 5 Jan 2022, at 22:32, Augie Fackler via llvm-dev <
> 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.


> >  * `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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20220106/23722615/attachment.html>