[LLVMdev] [RFC] Module Flags Metadata

[Bill Wendling]

On Jan 24, 2012, at 12:07 PM, Chandler Carruth wrote:

> On Tue, Jan 24, 2012 at 12:02 PM, Bill Wendling <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> 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 don't know of any pass which modifies metadata unless it knows what it's doing. And as pointed out, named metadata isn't stripped via normal methods. So I don't see how this will be a problem.

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

I understand what you're saying, and I agree to a certain extent. However, there is already a case where metadata may affect the semantics of the program. The 'fpaccuracy' metadata appears to have an affect on floating point calculations. But that's a side issue. The problem with named metadata is that it's not very well defined in the documentation. All that it says is that it's a collection of metadata nodes. So it's hard to argue with what its semantics and behavior is (or was) supposed to be.

What I'm saying is that named metadata is a method to pass this information along which doesn't require adding a new IR feature to LLVM. I say this because it would be modified only be passes which know how to modify it, it wouldn't be stripped via conventional means of stripping a program, and we would document how passes should handle this metadata.

-bw