<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 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>