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

[Mehdi AMINI via Phabricator via llvm-commits]

mehdi_amini added a comment.

In https://reviews.llvm.org/D29110#656629, @pcc wrote:

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


This is the problem and this is what I told you on IRC... This slipped in with your addition on global MD attachment, without enough scrutiny IMO. 
There should have been a dedicated RFC about using Metadata attachment for correctness related thing. I don't believe this happened (At least Duncan and I missed the discussion on this specific aspect if it happened).

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

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.


https://reviews.llvm.org/D29110