<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 9/11/2016 10:09 PM, Chandler Carruth
wrote:<br>
</div>
<blockquote
cite="mid:CAGCO0Kiki_8nMvqVa8H5xjSrKhYgb+yonjY4jB4_dOYSoJKkUw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_quote">
<div dir="ltr">On Thu, Sep 1, 2016 at 10:21 AM Friedman, Eli
via llvm-commits <<a moz-do-not-send="true"
href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">On
8/31/2016 4:19 PM, Daniel Berlin wrote:<br class="gmail_msg">
> In theory yes, in practice, it probably shouldn't.<br
class="gmail_msg">
><br class="gmail_msg">
> In particular, i would never expect *this* pass to
modify the IR.<br class="gmail_msg">
><br class="gmail_msg">
> Is there some reason things don't get cleaned up that
means this pass<br class="gmail_msg">
> has to clean them up?<br class="gmail_msg">
<br class="gmail_msg">
This isn't really modifying the IR: dead Constants aren't
actually part<br class="gmail_msg">
of the IR in the sense that they're not relevant to the
semantics of IR,<br class="gmail_msg">
and they're implicitly discarded if you dump the IR to a
file.<br class="gmail_msg">
<br class="gmail_msg">
Existing passes don't clean up dead Constants simply because
it isn't<br class="gmail_msg">
convenient; the standard accessors for modifying and erasing<br
class="gmail_msg">
instructions don't clean them up because it would lead to<br
class="gmail_msg">
use-after-free, and passes generally don't clean them up
because it<br class="gmail_msg">
would be mostly useless boilerplate.<br class="gmail_msg">
<br class="gmail_msg">
I can come up with some other solution if you want to insist
on the<br class="gmail_msg">
invariant that GlobalsAA isn't allowed to modify any data
structure<br class="gmail_msg">
associated with the module, but I don't really see a need.<br
class="gmail_msg">
</blockquote>
<div><br>
</div>
<div>I really don't think we should mutate the set of
constants in an analysis.</div>
<div><br>
</div>
<div>I think it is reasonable for other analyses to hold
pointers to constants and expect them to never go away even
if they become "dead". I suspect people view constants much
like types -- once they get a pointer to them, the pointer
remains immutable and reliable. I would want a *really*
compelling motivation before we remove that invariant.</div>
</div>
</div>
</blockquote>
<br>
We already have a bunch of passes which call
removeDeadConstantUsers... they're not analysis passes, but I don't
think that makes much of a difference in practice.<br>
<p>That said, it's probably not a big deal to come up with a version
which uses Constant::isConstantUsed() instead; I'll try to post a
new version soon.<br>
</p>
<p>-Eli<br>
</p>
<pre class="moz-signature" cols="72">--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project</pre>
</body>
</html>