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 9:11 PM, Nick Lewycky wrote:> 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?llvm-extract already copies over named metadata.> Should it keep a copy of every global metadata node that references a function?What do you mean by this? MDNodes cannot have references to global values. Or do you mean something like: !0 = metadata !{ metadata !"some_function" }> The same applies to bugpoint.Yup!> What if the NamedMDNode is used in codegen, and removing it removes the crash?Then it's a bug and should be fixed.> Simply put, I don't like this design, but my objections are weak and I lack an alternative plan.:-( The only other design I can think of (and have thought of) is "module attributes" as an IR-level feature. They would be similar to function attributes. But if we can get away without creating a new IR feature, all the better!> 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.-bw
Just to add to the renderscript example, the ARM ABI requires a build attribute to be emitted giving the size of wchar_t for library selection. Having a way to pass that from the frontend to backend would be absolutely ideal, and module level metadata/attributes seem fit for that purpose. -----Original Message----- From: cfe-dev-bounces at cs.uiuc.edu [mailto:cfe-dev-bounces at cs.uiuc.edu] On Behalf Of Bill Wendling Sent: 27 January 2012 05:59 To: Nick Lewycky Cc: cfe-dev at cs.uiuc.edu Developers; llvmdev at cs.uiuc.edu Mailing List Subject: Re: [cfe-dev] [LLVMdev] [RFC] Module Flags Metadata On Jan 24, 2012, at 9:11 PM, Nick Lewycky wrote:> Yeah, I can't think of any use for something that would pull outNamedMDNodes 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?llvm-extract already copies over named metadata.> Should it keep a copy of every global metadata node that references afunction? What do you mean by this? MDNodes cannot have references to global values. Or do you mean something like: !0 = metadata !{ metadata !"some_function" }> The same applies to bugpoint.Yup!> What if the NamedMDNode is used in codegen, and removing it removes thecrash? Then it's a bug and should be fixed.> Simply put, I don't like this design, but my objections are weak and Ilack an alternative plan. :-( The only other design I can think of (and have thought of) is "module attributes" as an IR-level feature. They would be similar to function attributes. But if we can get away without creating a new IR feature, all the better!> 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 inmost regards, but the MDNodes they contain may change as much as any mdnode. -bw _______________________________________________ cfe-dev mailing list cfe-dev at cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
On Jan 26, 2012, at 9:58 PM, Bill Wendling wrote:>> What if the NamedMDNode is used in codegen, and removing it removes the crash? > > Then it's a bug and should be fixed.Yup. That'd be equivalent of removing a used global variable. - Devang -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120127/50741b95/attachment.html>