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

[Augie Fackler via llvm-dev]

On Thu, Jan 6, 2022 at 12:22 PM Johannes Doerfert <
johannesdoerfert at gmail.com> wrote:

>
> On 1/6/22 09:23, Reid Kleckner via llvm-dev wrote:
> > On Thu, Jan 6, 2022 at 1:41 AM Nikita Popov via llvm-dev <
> > llvm-dev at lists.llvm.org> wrote:
> >
> >> An important bit I'm missing in this proposal is what the actual
> semantics
> >> of the "allocator" attribute are -- what optimizations is LLVM
> permitted to
> >> perform if this attribute is present?
> >> ...
> >> I assume the only optimization that "allocator" should control is the
> >> elimination of unused alloc+free pairs. Is that correct? Or are there
> other
> >> optimizations that should be bound to it?
> >>
> > Not to speak for Augie, but I think these predicates exist to support a
> > higher level goal of teaching LLVM to promote heap allocations to stack
> > allocations. LLVM can only currently do this when other passes (GVN+DSE)
> > promote all loads and stores to an allocation to registers, but you can
> > imagine building out more annotations to make other transforms possible.
> >
> If you want to do Heap2Stack, create an Attributor, seed AAHeapToStack
> for each function, run it to completion. It works for known
> malloc/alloc/calloc-like and free-like calls, so if you register your
> calls there (as we did for __kmpc_alloc_shared/__kmpc_free_shared) you
> will get heap2stack.
>

It's an explicit goal of this work that we not have to freeze the Rust
allocator function signatures and give LLVM Rust-specific knowledge. Rust
has been carrying patches that do exactly that in their fork of the latest
LLVM stable for years, but even then it occasionally bitrots and requires
maintenance to correctly identify the allocator functions. Doing this with
an attribute feels like it cleans up some technical debt, thus the
motivation to invest the time.

Thanks,
Augie


>
> Examples:
>
> https://github.com/llvm/llvm-project/blob/main/llvm/test/Transforms/Attributor/heap_to_stack.ll
>
> ~ Johannes
>
>
> >
> > _______________________________________________
> > 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/5f56f427/attachment.html>