[cfe-dev] [LLVMdev] [RFC] Module Flags Metadata

[Nick Lewycky]

Chandler Carruth wrote:
> On Tue, Jan 24, 2012 at 12:02 PM, Bill Wendling <wendling at apple.com
> <mailto:wendling at apple.com>> wrote:
>
>     On Jan 24, 2012, at 1:35 AM, Chandler Carruth wrote:
>
>      > On Wed, Jan 18, 2012 at 1:36 PM, Bill Wendling
>     <wendling at apple.com <mailto:wendling at apple.com>> wrote:
>      > Hello,
>      >
>      > This is a proposal for implementing "module flags". Please take a
>     look at this and give any feedback you may have.
>      >
>      > Thanks!
>      > -bw
>      >
>
>      > I have only one real comment -- this violates the contract and
>     spirit of LLVM's metadata design. You're specifically encoding
>     semantics in metadata, but the principle of metadata is that a
>     program with all metadata stripped has the same behavior as one with
>     the metadata still in place.
>      >
>      > I think what you're really talking about are Module-level
>     attributes much like we have function attributes. These have
>     inherently significant semantics, and must be handled explicitly,
>     not simply dropped when unknown.
>      >
>      > Anyways, that's my only real comment about the proposal. I think
>     you need something other than metadata to encode this.
>
>     I had thought of that too (and having a module-level attribute
>     scheme), but I was surprised when I found out that named metadata
>     wasn't "strippable" from modules. (You can't strip them via the
>     'opt' command.)
>
>
> I'm not claiming that we have a tool today that will strip named
> metadata for modules, I'm just claiming that the design of metadata, as
> Nick explained it to me originally and as he has re-explained it to me
> recently, operates under the assumption that metadata doesn't carry
> required semantics, it carries optional information.
>
>     Chris assured me that they were meant to stick around...
>
>
> Meant to is different from can change behavior if removed. This would
> make module-level named metadata obey a different set of constraints
> from all of the other named metadata we have. Those most definitely are
> stripped, corrupted, inverted and made up at the whims of the optimizer
> in several cases under the supposition that the code always remains
> valid....
>
> I'm really not opposed to something like named metadata (or named
> metadata itself) being persistent, and being required to be persistent.
> My only concern is with overloading a construct that wasn't designed
> with that in mind, and currently isn't consistently treated in that way
> even if it happens to work today at the module level.

Yeah, I can't think of any use for something that would pull out 
NamedMDNodes for no reason. That said, if you want this to work, please 
audit the module cloner at the very least (it should copy the NamedMDNodes).

But what would you do with llvm-extract? Should it keep a copy of every 
global metadata node that references a function? The same applies to 
bugpoint. What if the NamedMDNode is used in codegen, and removing it 
removes the crash? Simply put, I don't like this design, but my 
objections are weak and I lack an alternative plan.

On the other side, there is a precedent for doing this. For example, 
RenderScript uses metadata to carry reflection information in the .bc 
files; their pipeline has that nothing else will touch the .bc files 
from the time their SDK produces it to the time the phone consumes it, 
so they assume the metadata wil still be there. RS would break if 
NamedMDNodes were stripped out.

It seems to make sense to treat NamedMDNodes not unlike GlobalVariables 
in most regards, but the MDNodes they contain may change as much as any 
mdnode.

Nick