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

[Johannes Doerfert via llvm-dev]

On 1/6/22 11:32, Augie Fackler wrote:
> 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.

I don't mind using an attribute for allocation/deallocation functions,
it will make things more flexible. What I tried to say is that heap2stack
can fall out of the box if the proper functions know these are allocators/
deallocators.

~ Johannes


> 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