<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 1/6/22 7:37 AM, Augie Fackler via
llvm-dev wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAHcr6Hb3P8gqp9dS3b+pytmORTBrRGyByLHtNzJZOm3DjNEwbw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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"
moz-do-not-send="true">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"
moz-do-not-send="true">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." <br>
</div>
</div>
</div>
</blockquote>
<p>Ok, this point needs amplified. I was actually thinking about
this just yesterday.</p>
<p>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. <br>
</p>
<p>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. <br>
</p>
<p>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.</p>
<p>Philip<br>
</p>
</body>
</html>