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

[Johannes Doerfert via llvm-dev]

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