search for: metadatacontext

...ears that the debug information is >> attached as metadata, but what is the easiest way to extract the >> filename and line number information out of this metadata? >> >> > > Something like this (you can of course cache TheMetadata and MDDbgKind) > > llvm::MetadataContext *TheMetadata = M->getContext().getMetadata(); > MDDbgKind = TheMetadata->getMDKind("dbg"); > if (MDDbgKind) { > if (MDNode *Dbg = TheMetadata->getMD(MDDbgKind, I)) { > DILocation Loc(Dbg); > ... > Loc.getDirectory() > Loc.getFilename() > Loc....

Török Edwin wrote: > [snip] >>> Something like this (you can of course cache TheMetadata and MDDbgKind) >>> >>> llvm::MetadataContext *TheMetadata = M->getContext().getMetadata(); >>> MDDbgKind = TheMetadata->getMDKind("dbg"); >>> if (MDDbgKind) { >>> if (MDNode *Dbg = TheMetadata->getMD(MDDbgKind, I)) { >>> DILocation Loc(Dbg); >>> ... >>>...

...t; information is attached as metadata, but what is the easiest way to >>> extract the filename and line number information out of this metadata? >>> >>> >> >> Something like this (you can of course cache TheMetadata and MDDbgKind) >> >> llvm::MetadataContext *TheMetadata = M->getContext().getMetadata(); >> MDDbgKind = TheMetadata->getMDKind("dbg"); >> if (MDDbgKind) { >> if (MDNode *Dbg = TheMetadata->getMD(MDDbgKind, I)) { >> DILocation Loc(Dbg); >> ... >> Loc.getDirectory() >...

...s the memory usage penalty of that on a > large program? I have not measured that yet. > If we're willing to pay this memory cost, even for programs that aren't > using debug info, why not just store pointer to a linked list of metadata > info in the Instruction and remove the MetadataContext? If it's a 10% > performance win for debug info we should be able to get the exact same win > across the board for all metadata with no cost beyond what your patch > already proposes. It all depends on how metadata is used. I am myself not very thrilled about this patch (hence request...

Dear LLVMers, I'm updating some code to use the new LLVM 2.7 API. One piece of this code uses the findStopPoint() function to find the source filename and line number information of an instruction. What is the best way to do this under LLVM 2.7 now that the stop point intrinsic has been removed? It appears that the debug information is attached as metadata, but what is the easiest way

...t > intrinsic has been removed? It appears that the debug information is > attached as metadata, but what is the easiest way to extract the > filename and line number information out of this metadata? > Something like this (you can of course cache TheMetadata and MDDbgKind) llvm::MetadataContext *TheMetadata = M->getContext().getMetadata(); MDDbgKind = TheMetadata->getMDKind("dbg"); if (MDDbgKind) { if (MDNode *Dbg = TheMetadata->getMD(MDDbgKind, I)) { DILocation Loc(Dbg); ... Loc.getDirectory() Loc.getFilename() Loc.getLineNumber() Loc.getColumnNum...

On 03/16/2010 05:30 PM, John Criswell wrote: > Török Edwin wrote: >> [snip] >>>> Something like this (you can of course cache TheMetadata and MDDbgKind) >>>> >>>> llvm::MetadataContext *TheMetadata = M->getContext().getMetadata(); >>>> MDDbgKind = TheMetadata->getMDKind("dbg"); >>>> if (MDDbgKind) { >>>> if (MDNode *Dbg = TheMetadata->getMD(MDDbgKind, I)) { >>>> DILocation Loc(Dbg); >>>>...

...ointer to Instruction (a WeakVH DbgInfo). What's the memory usage penalty of that on a large program? If we're willing to pay this memory cost, even for programs that aren't using debug info, why not just store pointer to a linked list of metadata info in the Instruction and remove the MetadataContext? If it's a 10% performance win for debug info we should be able to get the exact same win across the board for all metadata with no cost beyond what your patch already proposes. Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/piper...

On Thu, Nov 26, 2009 at 2:31 PM, Nick Lewycky <nicholas at mxc.ca> wrote: > Hi Devang, > > Before I get to the contents of this particular patch, I have a higher-level > design question. Why is metadata stored off the LLVMContext? Why do we have FPConstants, IntConstants etc.. in LLVMContext ? :) > That seems like > the wrong place to me, this data is all specific to the

...ign question. Why is metadata stored off the LLVMContext? That seems like the wrong place to me, this data is all specific to the particular module. Specifically, a single MDNode may not cross modules, and if a module is destroyed we should eliminate all the metadata that came with it. So, why MetadataContext at all? Nick Devang Patel wrote: > Hi All, > > Now, in llvm trunk we support custom metadata, which can be attached > with llvm instructions. One of the user is "debugging information". > This user is special (not just because it is in llvm svn tree:) > because wheneve...

...) [other parameter attributes]) for example: define void @f() metadata(!foo !bar) { ... } ;attach bar to function f define void @f(i8 metadata(!foo !bar) a) { ... } ;attach bar to argument a so, i think i shoud: 1.change "typedef DenseMap<const Instruction *, MDMapTy> MDStoreTy; in MetadataContextImpl" to "typedef DenseMap<const Value *, MDMapTy> MDStoreTy;" and the corresponding method in MetadataContextImpl and MetadataContext? 2.modify the code of asm reader/writer 3.modify bitcode reader/writer any comment or advice is appreciate best regards --ether

Hi All, Now, in llvm trunk we support custom metadata, which can be attached with llvm instructions. One of the user is "debugging information". This user is special (not just because it is in llvm svn tree:) because whenever debug info is available, it is likely that corresponding metadata is attached with almost all instructions. In other words, usually it is all or nothing. This