similar to: [LLVMdev] More metadata questions

Hello, Thank you very much for the pointers. I am are able to create new MDNodes, filled with some constants, and attach them to llvm instructions. However, the metadata map is not getting updated as expected. For example, instead of the expected new entry !n = metadata !{some values} we are getting !n = metadata !{null} Do you know what might be wrong? Do we need to enter the MDNodes into the

> Dear llvm-ers, > I am trying to attach a customized metadata to llvm instructions. > Let's say, I want to attach some number to each instruction. > I am trying to use > > void Instruction::setMetadata(unsigned KindID, MDNode* Node) > > but I am not sure how to create a brand new instance of an MDNode. > Do you have any code samples demonstrating how to do that?

On 12/21/11 11:24 PM, Oksana Tkachuk wrote: > Hello, > Thank you very much for the pointers. > I am are able to create new MDNodes, filled with some constants, and > attach them > to llvm instructions. However, the metadata map is not getting updated > as expected. > For example, instead of the expected new entry If you look at PoolMDPass::runOnModule(), you'll see that

Wouldn't it be simpler to name the metadata based on the hash of the content? Then you could use a normal reference to that metadata without needing to create a new type or teach the rest of llvm how to use it... On Fri, Jun 21, 2013 at 3:22 PM, Manman Ren <mren at apple.com> wrote: > > A summary of options for issue #3: > 3> To actually access the MDNode referenced via

More details please :] What do you mean by "name the metadata"? Are you referring to the name field of the MDNode? Thanks, Manman On Jun 21, 2013, at 7:19 AM, David Blaikie wrote: > > On Jun 21, 2013 1:19 AM, "Jeremy Lakeman" <Jeremy.Lakeman at gmail.com> wrote: > > > > Wouldn't it be simpler to name the metadata based on the hash of the content?

On Jun 21, 2013 1:19 AM, "Jeremy Lakeman" <Jeremy.Lakeman at gmail.com> wrote: > > Wouldn't it be simpler to name the metadata based on the hash of the content? Then you could use a normal reference to that metadata without needing to create a new type or teach the rest of llvm how to use it... Sounds reasonable (probably with some nice prefix to get these things a

On Jun 21, 2013, at 10:18 AM, David Blaikie wrote: > On Fri, Jun 21, 2013 at 10:13 AM, Manman Ren <mren at apple.com> wrote: >> >> More details please :] >> What do you mean by "name the metadata"? Are you referring to the name field >> of the MDNode? > > Using named metadata rather than unnamed metadata. > > rather than having: > >

On Fri, Jun 21, 2013 at 10:13 AM, Manman Ren <mren at apple.com> wrote: > > More details please :] > What do you mean by "name the metadata"? Are you referring to the name field > of the MDNode? Using named metadata rather than unnamed metadata. rather than having: !llvm.hardref = !{metadata !"foo.h::myClass", !3, metadata !"bar.h:myEnum", !4} ...

A summary of options for issue #3: 3> To actually access the MDNode referenced via the hash value, we need to perform a lookup from the hash value to find the corresponding MDNode. The questions are where to store this map and how to keep it up-to-date when a MDNode is replaced. --------------------- Option a) a map in DwarfDebug, AsmWriter and DIBuilder, modify access functions in DI classes

Dear llvm-ers, I am trying to attach a customized metadata to llvm instructions. Let's say, I want to attach some number to each instruction. I am trying to use void Instruction::setMetadata(unsigned KindID, MDNode* Node) but I am not sure how to create a brand new instance of an MDNode. Do you have any code samples demonstrating how to do that? Due to some tool dependencies, I am using

-llvm-commits, +llvmdev > On Oct 2, 2014, at 2:57 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > > Author: dexonsmith > Date: Thu Oct 2 16:56:57 2014 > New Revision: 218914 > > URL: http://llvm.org/viewvc/llvm-project?rev=218914&view=rev > Log: > DI: Fold constant arguments into a single MDString > > This patch addresses the first

>>> Here is another version of the patch. This one includes also a small patch to llvm-gcc so that it generates the type metadata for structures and classes. This one also generates and parses correctly the metadata for .ll files. No .bc support yet. The biggest problem with this version is that it breaks when the compiler/linker performs type reductions, and I don't understand

In LLVM IR metadata is used to attach auxiliary information with various IR constructs. Currently metadata information is represented using MDNode and MDString. The metadata can refer to LLVM values but these references are not counted as regular "uses" of these values because metadata is maintained 'on the side'. This ensures that the optimizer is not influenced by auxiliary

> On 2014-Nov-10, at 08:30, Chris Lattner <clattner at apple.com> wrote: > >> On Nov 9, 2014, at 5:02 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: >> In response to my recent commits (e.g., [1]) that changed API from >> `MDNode` to `Value`, Eric had a really interesting idea [2] -- split >> metadata entirely from the `Value` hierarchy, and

On Thu, Jun 20, 2013 at 5:25 PM, Manman Ren <mren at apple.com> wrote: > > On Jun 20, 2013, at 5:18 PM, David Blaikie <dblaikie at gmail.com> wrote: > > On Thu, Jun 20, 2013 at 5:13 PM, Manman Ren <mren at apple.com> wrote: > > > On Jun 20, 2013, at 4:52 PM, David Blaikie wrote: > > On Thu, Jun 20, 2013 at 4:45 PM, Manman Ren <mren at apple.com>

Hi All, Type uniquing for C++ is in. Some data for Xalan with -flto -g: 9.9MB raw dwarf size, peak memory usage at 2.8GB The raw dwarf size was 58MB, memory usage was 7GB back in May, 2013. Other efforts at size reduction helped, and type uniquing improved on top of those. Data on building clang with "-flto -g" after type uniquing: 3.4GB MDNodes after parsing all bc files, 7GB

Pekka Nikander wrote: >>>> Here is another version of the patch. This one includes also a small patch to llvm-gcc so that it generates the type metadata for structures and classes. This one also generates and parses correctly the metadata for .ll files. No .bc support yet. The biggest problem with this version is that it breaks when the compiler/linker performs type reductions, and

Dear all, I am looking to output assembly comments in my emitPrologue() function, just for my own readability. Searching for a way to do this found me this thread - http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/043722.html, which says that the best way to output comments from somewhere like emitPrologue() is to: 1. Create an MDString for the comment. 2. Attach it to an LLVM

On Jul 27, 2009, at 10:10 AM, Devang Patel wrote: > In LLVM IR metadata is used to attach auxiliary information with > various IR constructs. Currently metadata information is represented > using MDNode and MDString. The metadata can refer to LLVM values but > these references are not counted as regular "uses" of these values > because metadata is maintained 'on the

On Oct 5, 2010, at 11:23 PM, Nick Lewycky wrote: >> >> Here is another version of the patch. This one includes also a small patch to llvm-gcc so that it generates the type metadata for structures and classes. This one also generates and parses correctly the metadata for .ll files. No .bc support yet. The biggest problem with this version is that it breaks when the compiler/linker