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

[Philip Reames via llvm-dev]

On 1/6/22 7:37 AM, Augie Fackler via llvm-dev wrote:
>
>
> On Thu, Jan 6, 2022 at 10:23 AM Reid Kleckner <rnk at google.com 
> <mailto: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 <mailto: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."

Ok, this point needs amplified.  I was actually thinking about this just 
yesterday.

In C/C++, there's a debate about whether a call to malloc is 
"observable".  That is, are statistics collected by your malloc 
information about e.g. allocation count part of the program state which 
must be observed.  If the answer is "yes", then most allocation 
eliminations are unsound.  Note that most other languages choose a 
strong "no" and thus allocation elimination is sound and worthwhile.

I had been planning to send a proposal for making the "is observable" 
state of an allocator routine explicit.  (I hadn't yet sat down to 
figure out how to express that, so TBD...)  My motivation is to support 
allocation eliminations optimizations upstream with clean LIT testing.

Augie, are there *other* semantics you want to attach to the allocator 
attribute?  As Nikita said, we really need a list of the intended 
semantics.  Most likely, we'll end up splitting them into individual 
attributes (and use of existing ones), so having a list of concrete 
examples to work with is important.

Philip

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20220106/cdda1126/attachment.html>