search for: mdstrings

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

> 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?

Hello, I propose a new syntax for metadata strings (MDStrings) which would allow string data to be spread over multiple lines: !0 = metadata !{metadata !""" hello world """} The special three-quote sequence marks the beginning and end of a multi-line string. This syntax could have a variety of uses, but of particular interest...

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

...d the problem that you pointer out that machine instructions refer to LLVM-IR, but I don’t think that metadata is the right container for them. Nadav On Jun 26, 2013, at 3:29 PM, Dan Gohman <dan433584 at gmail.com> wrote: > Hello, > > I propose a new syntax for metadata strings (MDStrings) which would allow string data to be spread over multiple lines: > > !0 = metadata !{metadata !""" > hello > world > """} > > The special three-quote sequence marks the beginning and end of a multi-line string. > > This syntax could have a...

So, an update. I have managed to generate comments, although it does create a non-existent instruction. My method is as follows (and I would appreciate any comments on how to do it "better", although note that this won't make it into the final code :).) 1. I declared a "fake" instruction type to hold comments, ala: class FakeInst<dag outs, dag ins, string asmstr,

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

On Jun 26, 2013, at 4:18 PM, Eric Christopher <echristo at gmail.com> wrote: > (Note, this is the first I've heard of this plan and just figured it out myself) Yes, this is also the first time I heard about this and I haven’t had a chance to think about this problem too deeply. > > So inverting it so that MI contains LLVM IR instead of the other way > around? Then

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

>>> 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

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

On Jun 26, 2013, at 3:51 PM, Chandler Carruth <chandlerc at google.com> wrote: > Can you suggest an alternative solution? Can you describe why you don't think metadata is the right container? This alone isn't really helpful at moving us toward something that there has been widespread agreement LLVM needs. Hi Chandler, Sure, we can talk about serializing MF. But the discussion

..." after type uniquing: 3.4GB MDNodes after parsing all bc files, 7GB MDNodes after linking all bc files 4.6GB DIEs 4G MCContext --> The memory usage is still too big. So how to reduce the memory footprint at MDNode level: 1> Combine integers into MDString and further combining MDStrings (see PR17891) A partial implementation on the important debug info nodes can reduce the MDNodes from 7GB to 5.7GB 2> Release MDNodes that are only used by source modules (I will send out a proposal) An estimation based on partial implementation: this will reduce MDNodes from 5.7...

...se several viable alternatives to representing > information on OpenMP directives and clauses while keeping general > design approach intact. > > Some things that we considered: > > a) Represent information on types of directives and clauses as > constant expressions instead of MDStrings. > b) Place MDStrings with identifiers of directives and clauses directly > into intrinsic calls instead of metadata. > c) Do not represent clauses as separate intrinsics with references to > metadata; instead, put a list of references to metadata for all > clauses associated with a...

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

...========= It is possible to propose several viable alternatives to representing information on OpenMP directives and clauses while keeping general design approach intact. Some things that we considered: a) Represent information on types of directives and clauses as constant expressions instead of MDStrings. b) Place MDStrings with identifiers of directives and clauses directly into intrinsic calls instead of metadata. c) Do not represent clauses as separate intrinsics with references to metadata; instead, put a list of references to metadata for all clauses associated with a directive at the end of m...

On Wed, Jun 26, 2013 at 3:46 PM, Nadav Rotem <nrotem at apple.com> wrote: > But I think that serialization of MachineFunction should not be done in > metadata. I understand the problem that you pointer out that machine > instructions refer to LLVM-IR, but I don’t think that metadata is the right > container for them. Can you suggest an alternative solution? Can you describe

Hi, I hope I'm not too annoying with my newbie questions. I've read the new (great!) wiki about the DI* classes, and I still can't figure out how to insert metadata into the LLVM IR. Let's say that I want to have two passes, one that creates some metadata string and inserts it into the IR, and the second one that reads it and acts according to what it finds (or doesn't find).

...perand named >> CodeViewTypes, which points to the new DICodeViewTypes node that describes >> the CodeView type information for the compilation unit. >> >> >> >> The DICodeViewTypes node contains two operands: >> >> - TypeRecords, an array of MDStrings containing the actual >> CodeView type records for the compilation unit, sorted in ascending order >> of type index. >> >> - UDTSymbols, and array of DICodeViewUDT nodes describing the >> user-defined types (class/struct/union/enum) for which CodeView symbol &...