[PATCH] D29110: LangRef: Document the allowed metadata dropping transforms.

Peter Collingbourne via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Jan 25 12:58:43 PST 2017


pcc added a comment.

In https://reviews.llvm.org/D29110#656666, @mehdi_amini wrote:

> In https://reviews.llvm.org/D29110#656660, @pcc wrote:
>
> > >> I like the idea of teaching GlobalDCE about llvm.compiler.used + associated, it would allow us to move that attribute out of the set of "attributes as MD*" without inhibiting DCE.
> > >> 
> > >> I'm not sure how that approach would work for type metadata though.
> > > 
> > > I haven't thought about type metadata in particular, and I'm not against attaching a specific property to globals for what is currently the "type metadata", at least on the principle (reusing the MD infrastructure with a different API to differentiate is an option, I haven't given much though about it, and an approach like the one I mentioned for the "associated" is likely preferable when possible). 
> > >  What I'm worried about is mixing the generic opaque attachment that are considered to always be possible to be ignored with one that can't, for the same reasons exposed by Sanjoy and Krzysztof.
> >
> > Fair enough. It seems like a reasonable goal to have straightforward ways to
> >
> > 1. copy information from one global to another while preserving correctness (something like the `copyAttributes` and `copyMetadata` I proposed earlier)
> > 2. drop all the opaque attachments (metadata, or a subset of it, or whatever) while preserving correctness As part of getting there, we can figure out the best way to move type and absolute_symbol into the right places in that mechanism.
> >
> >   Do you agree? If so, I will file a bug to keep track of that work.
>
>
> Sure. 
>  I don't think there is any emergency on the implementation side, as long as we have somehow an agreement on the direction.


https://llvm.org/bugs/show_bug.cgi?id=31759


https://reviews.llvm.org/D29110





More information about the llvm-commits mailing list