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

[Chandler Carruth]

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'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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120124/90d16107/attachment.html>