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.) Chris assured me that they were meant to stick around... -bw
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/llvm-dev/attachments/20120124/90d16107/attachment.html>
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
>> 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.This is a simplified understanding of semantics. As I understand, the expected metadata design behavior is that optimizer/transformations are not responsible to preserve any _relationship_ between a User and a MDNode. For example, if a MDNode is "using" a User then optimizer can remove the User without bothering about what happens to the MDNode. Same way, If MDNode is attached to an Instruction then optimizer can mutate, delete or replace the Instruction while completely ignoring attached MDNode. NamedMDNode is a simple collection of metadata nodes at module level. By design NamedMDNode does not have any uses and it can not directly hold any values (use any values) other then MDNode, so there is not any reason for optimizer to worry about it.>> >> 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.)- Devang -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120124/866f4087/attachment.html>
On Tue, Jan 24, 2012 at 3:39 PM, Devang Patel <dpatel at apple.com> wrote:> This is a simplified understanding of semantics. As I understand, the > expected metadata design behavior is that optimizer/transformations are not > responsible to preserve any _relationship_ between a User and a MDNode. For > example, if a MDNode is "using" a User then optimizer can remove the User > without bothering about what happens to the MDNode. Same way, If MDNode is > attached to an Instruction then optimizer can mutate, delete or replace the > Instruction while completely ignoring attached MDNode. > > NamedMDNode is a simple collection of metadata nodes at module level. By > design NamedMDNode does not have any uses and it can not directly hold any > values (use any values) other then MDNode, so there is not any reason for > optimizer to worry about it. >Thanks Devang, I think this reasoning helps me have a consistent model for what is and isn't allowed when transforming metadata. To touch on Bill's mail, I think one thing that would help this discussion (and others I've had recently) is to get some of these semantics of metadata written down in the LangRef so that we at least have a documented set of rules to follow. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120124/be02cdd9/attachment.html>
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
On Jan 24, 2012, at 3:39 PM, Devang Patel wrote:> >>> 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. > > > This is a simplified understanding of semantics. As I understand, the expected metadata design behavior is that optimizer/transformations are not responsible to preserve any _relationship_ between a User and a MDNode. For example, if a MDNode is "using" a User then optimizer can remove the User without bothering about what happens to the MDNode.Right.> Same way, If MDNode is attached to an Instruction then optimizer can mutate, delete or replace the Instruction while completely ignoring attached MDNode.However, this isn't necessarily true. For example, it would seem to be within the spirit of LLVM's metadata design to describe the range of values that a given instruction might have. However, if the optimizer mutates the instruction (and preserves program correctness by mutating its operand instructions to compensate), then that metadata could easily become incorrect. Right now, there aren't any rules about what metadata can do, or what optimizers must do to preserve it. It's sort of the "head in the sand" level of conceptual maturity. Dan