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

Wed Jan 25 11:11:59 PST 2017

mehdi_amini added a comment.

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.

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

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

https://reviews.llvm.org/D29110