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 means, using Metadata Store to access debugging information attached with each llvm instruction is expensive, in terms of compile time. If debugging information is directly stored inside llvm::Instruction then it speeds up compile time. In my measurements this speeds up LLVMContext.cpp compile time (-O0 -g) by almost 10%. I do not see any strong reason to give up this gain. Thoughts ? I am attaching tentative patch with this email. - Devang -------------- next part -------------- A non-text attachment was scrubbed... Name: smd.diff Type: application/octet-stream Size: 6902 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20091125/b220c2ee/attachment.obj>
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? 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 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 means, using Metadata > Store to access debugging information attached with each llvm > instruction is expensive, in terms of compile time. If debugging > information is directly stored inside llvm::Instruction then it speeds > up compile time. In my measurements this speeds up LLVMContext.cpp > compile time (-O0 -g) by almost 10%. I do not see any strong reason to > give up this gain. > > Thoughts ? I am attaching tentative patch with this email. > - > Devang > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
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 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.Metadata is not connected with a Module. Module does not own metadata. Metadata is on the side, observing Values. - Devang
Hi Devang,> + WeakVH DbgInfo;This holds an MDNode* which contains information which is used to look up a DebugLoc? It sounds like there's an unnecessary layer of indirection here. Would it make sense to make Instruction just have a DebugLoc member instead? I don't know what that would mean for the getMD API, but my understanding of the Metadata design was that things like nsw, tail, and align could eventually be considered Metadata, so perhaps there's a way to handle this. Also, please mention the issue of increasing the size of Instruction for non-debug compilation and indicate what the plan is. A few misc comments:> - return MDHandlerNames[Name] = Count + 1; > + return MDHandlerNames[Name] = Count + 1 + 1;This code is non-obvious enough to justify a comment.> - // MD Handlers are numbered from 1. > + // MD Handlers are numbered from 1.Please don't add trailing whitespace, especially to lines which aren't otherwise changed.> +#include "llvm/Support/Timer.h"...> + Timer *MDTimer;This isn't related to the rest of the patch. Dan On Nov 25, 2009, at 10:41 AM, 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 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 means, using Metadata > Store to access debugging information attached with each llvm > instruction is expensive, in terms of compile time. If debugging > information is directly stored inside llvm::Instruction then it speeds > up compile time. In my measurements this speeds up LLVMContext.cpp > compile time (-O0 -g) by almost 10%. I do not see any strong reason to > give up this gain. > > Thoughts ? I am attaching tentative patch with this email. > - > Devang > <smd.diff>_______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev