Dan Gohman wrote:> On Sep 11, 2009, at 9:57 AM, Chris Lattner wrote: > > >> Devang's work on debug info prompted this, thoughts welcome: >> http://nondot.org/sabre/LLVMNotes/ExtensibleMetadata.txt > > The document mentions "instructions" a lot. We'll want to be able to > apply metadata to ConstantExprs as well at least, if not also Arguments > (think noalias) and other stuff, so it seems best to just talk about > "values" instead, and DenseMap<Value *, ...> instead of > DenseMap<Instruction *, ...>.I'm wondering that too. Can we replace LLVM function attributes with metadata? There's been some pushback to adding new function attributes in the past and it would be nice to be able to prototype new ones without having to change all of the vm core. Nick
On Sep 11, 2009, at 7:17 PM, Nick Lewycky wrote:> Dan Gohman wrote: >> On Sep 11, 2009, at 9:57 AM, Chris Lattner wrote: >>> Devang's work on debug info prompted this, thoughts welcome: >>> http://nondot.org/sabre/LLVMNotes/ExtensibleMetadata.txt >> The document mentions "instructions" a lot. We'll want to be able to >> apply metadata to ConstantExprs as well at least, if not also >> Arguments >> (think noalias) and other stuff, so it seems best to just talk about >> "values" instead, and DenseMap<Value *, ...> instead of >> DenseMap<Instruction *, ...>. > > I'm wondering that too. Can we replace LLVM function attributes with > metadata? There's been some pushback to adding new function > attributes in the past and it would be nice to be able to prototype > new ones without having to change all of the vm core.The pushback has been about adding lots of weird and special purpose extensions, not the encoding. -Chris
Chris Lattner wrote:> > On Sep 11, 2009, at 7:17 PM, Nick Lewycky wrote: > >> Dan Gohman wrote: >>> On Sep 11, 2009, at 9:57 AM, Chris Lattner wrote: >>>> Devang's work on debug info prompted this, thoughts welcome: >>>> http://nondot.org/sabre/LLVMNotes/ExtensibleMetadata.txt >>> The document mentions "instructions" a lot. We'll want to be able to >>> apply metadata to ConstantExprs as well at least, if not also Arguments >>> (think noalias) and other stuff, so it seems best to just talk about >>> "values" instead, and DenseMap<Value *, ...> instead of >>> DenseMap<Instruction *, ...>. >> >> I'm wondering that too. Can we replace LLVM function attributes with >> metadata? There's been some pushback to adding new function attributes >> in the past and it would be nice to be able to prototype new ones >> without having to change all of the vm core. > > The pushback has been about adding lots of weird and special purpose > extensions, not the encoding.The bar is higher for getting something into the vm core, as it should be. It sounds like we're planning to permit special purpose metadata which is why I asked. If nothing else, it would be more convenient to prototype new extensions to find out what they're really worth. Nick
2009/9/12 Nick Lewycky <nicholas at mxc.ca>:> I'm wondering that too. Can we replace LLVM function attributes with > metadata? There's been some pushback to adding new function attributes > in the past and it would be nice to be able to prototype new ones > without having to change all of the vm core.I just wonder how stable that would become as time passes by. It is true that enabling the addition of metadata as part of the structure is good for specialized optimizations that are not represented internally (or relevant) in the LLVM core, but there is a practical limit on what you can do. My (humble) opinion is that basic language structure, such as function attributes, should still be part of the core. And if there isn't always easy ways of getting them and passing them through we should make it easier... in the core. Metadata is a completely different beast. It's good for things that only your own optimization pass or machine code will understand. It's an additional rather than required information, which the lack of would be completely harmless. I completely agree with the text argument that the demand (and necessity) for metadata is increasing, but that doesn't mean we should transform everything into it. The RDF [1] developments sent a clear message that metadata per se are too loose to hold value. We need a fixed, basic structure on where to stick metadata, otherwise it'd just be a big slimy blob of untreatable data. My two cents... cheers, --renato [1] http://www.w3.org/RDF/ Reclaim your digital rights, eliminate DRM, learn more at http://www.defectivebydesign.org/what_is_drm