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

[Peter Collingbourne via Phabricator via llvm-commits]

pcc added a comment.

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

> In https://reviews.llvm.org/D29110#656562, @pcc wrote:
>
> > In https://reviews.llvm.org/D29110#656551, @kparzysz wrote:
> >
> > > In https://reviews.llvm.org/D29110#656480, @pcc wrote:
> > >
> > > > So would it solve the problem if we don't call it metadata? They are "attributes which happen to be represented using the MD* classes".
> > >
> > >
> > > Would it still look like metadata to someone who has not read that piece of documentation?  Would this information invalidate previously correct understanding of the IR?
> > >
> > > Imagine that some user somewhere wrote their own LLVM-based compiler that strips all metadata.  If that compiler generated a correct code prior to this change, would it potentially generate a wrong code afterwards?
> >
> >
> > You can make the same argument for stripping thread_local (etc).
>
>
> And stripping function entirely, and stripping instructions, etc... I don't get your point: there has always been a clear separation between IR and Metadata attachment.


I think we can maintain that separation at the API level (see my message to Krzysztof).

>> Fundamentally there are always going to be properties that need to be preserved for correctness no matter how we represent them
> 
> Right, and there has always been a very clear rule about metadata attachment: *you can't use them for correctness*.

Can you show me where that rule is documented for attachments on globals? I know that I did not have this rule in mind when I implemented them. I always viewed them as analogous to global named metadata (which already needs to be preserved for correctness) containing a reference to the global that they are attached to.

>> and there's no magical way to make sure that clients don't make mistakes.
> 
> See what I mentioned before for intrinsic vs instruction.
> 
> Then there is also how one approach the design of a given feature in the first place: for instance the !associated does not have to carry correctness: for instance you can add the variable to compiler.user to model the correctness part, and use the MD to instruct a pass that it can ignore the compiler.used for a specific optimization.
>  I.e. the MD can be safely dropped, is preserved on a best-effort basis, and optionally passes that are taught about it can optimize better: there's nothing magic about it.

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. After thinking about it a little I have some ideas for how type information could be represented without metadata. They somewhat resemble my very first proposal to add type information to the IR (http://lists.llvm.org/pipermail/llvm-dev/2015-January/081254.html), but a lot would need to be fleshed out and I'm not sure if it would work. I am also reluctant to go back to the drawing board again after designing/implementing a representation for type information no less than three times already.


https://reviews.llvm.org/D29110