<div class="gmail_quote">On Tue, Jan 24, 2012 at 12:02 PM, Bill Wendling <span dir="ltr"><<a href="mailto:wendling@apple.com">wendling@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Jan 24, 2012, at 1:35 AM, Chandler Carruth wrote:<br>
<br>
> On Wed, Jan 18, 2012 at 1:36 PM, Bill Wendling <<a href="mailto:wendling@apple.com">wendling@apple.com</a>> wrote:<br>
> Hello,<br>
><br>
> This is a proposal for implementing "module flags". Please take a look at this and give any feedback you may have.<br>
><br>
> Thanks!<br>
> -bw<br>
><br>
<br>
</div><div class="im">> 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.<br>

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

><br>
> Anyways, that's my only real comment about the proposal. I think you need something other than metadata to encode this.<br>
<br>
</div>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.)</blockquote>
<div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Chris assured me that they were meant to stick around...<br></blockquote><div><br></div><div>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....</div>
<div><br></div><div>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.</div>
</div>