<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 6, 2022 at 10:23 AM Reid Kleckner <<a href="mailto:rnk@google.com">rnk@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Thu, Jan 6, 2022 at 1:41 AM Nikita Popov via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">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?<br></div><div>...</div><div>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?</div></div></div></blockquote><div><br></div><div>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.</div></div></div></blockquote><div><br></div><div>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." </div></div></div>