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

[Augie Fackler via llvm-dev]

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>