[PATCH] D24104: Make GlobalsAA ignore dead constant expressions.

Chandler Carruth via llvm-commits llvm-commits at lists.llvm.org
Sun Sep 11 22:09:11 PDT 2016


On Thu, Sep 1, 2016 at 10:21 AM Friedman, Eli via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> On 8/31/2016 4:19 PM, Daniel Berlin wrote:
> > In theory yes, in practice, it probably shouldn't.
> >
> > In particular, i would never expect *this* pass to modify the IR.
> >
> > Is there some reason things don't get cleaned up that means this pass
> > has to clean them up?
>
> This isn't really modifying the IR: dead Constants aren't actually part
> of the IR in the sense that they're not relevant to the semantics of IR,
> and they're implicitly discarded if you dump the IR to a file.
>
> Existing passes don't clean up dead Constants simply because it isn't
> convenient; the standard accessors for modifying and erasing
> instructions don't clean them up because it would lead to
> use-after-free, and passes generally don't clean them up because it
> would be mostly useless boilerplate.
>
> I can come up with some other solution if you want to insist on the
> invariant that GlobalsAA isn't allowed to modify any data structure
> associated with the module, but I don't really see a need.
>

I really don't think we should mutate the set of constants in an analysis.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160912/d5104fdb/attachment.html>


More information about the llvm-commits mailing list