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

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

On Thu, Jan 6, 2022 at 10:23 AM Reid Kleckner <rnk at google.com> 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.
>
Yep. Any kind of noalias annotations should be separate, and we can just
keep the `allocator` attribute down to just "you can optimize this pair of
calls away if circumstances are right."
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20220106/ac7f4034/attachment.html>

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