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

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.

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

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>