[LLVMdev] RFP: Metadata is being used poorly to paper over missing IR constructs

[Chris Lattner]

On Jan 9, 2015, at 1:45 PM, Chandler Carruth <chandlerc at gmail.com> wrote:
> On Fri, Jan 9, 2015 at 1:21 PM, Chris Lattner <clattner at apple.com <mailto:clattner at apple.com>> wrote:
> > #2
> > We need to make module flags a first class entity of the module, just like datalayout:
> >
> >   &flag = ....
> >
> > (syntax shamelessly stolen from Duncan's suggestion in IRC)
> 
> I disagree.  The concerns about “stability” of metadata don’t apply to module-level metadata that doesn’t refer to the other IR in the module.  A nice thing about module-level metadata is that it eliminates the “need" to encode features like command line flags directly in the IR in a custom tailored way.  There should be no need to design bitcode and .ll syntax for new things like command line flags.  If we had module-level metadata back in day 1, targetdata would be using it...
> 
> Calling whatever it is that encodes things in the module "metadata" makes that term less useful. I don't really care about the syntax or encoding, but I do very much care that we separate the terminology and APIs used for entities that have very fundamentally different behavior constraints.
> 
> Metadata is discardable without changing correctness. These other things are not. We need two different ways to describe and manipulate them so that we don't continually get confused as to which case we are dealing with. And "module-level" isn't even a good predicate because some things at the module level are meeting the same constraints as the rest of metadata -- namely, debug information.

I can see what you’re saying, but I think you’ll end up with something that is “module metadata that is string-only” or something.  I don’t know if the clarity of the model you’re looking for is worth adding another similar-but-different facility, but I suppose we can discuss that when someone actually has time to implement such a thing.

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150109/3c739510/attachment.html>