search for: processmodule

...e analysis phase. If the object does not exist, then I compile the module, put object file into a cache, and then proceed to a module analysis phase. In other words: let object = cache.getObject(module); if object == null { object = compile(module) cache.putObject(object, module) } processModule(module) When I run my program two times, then I basically analyze two different modules, even though they are loaded from the same bitcode file. Please, let me know if more information/clarification is needed. Any hints, suggestions, and recommendations are more than welcome :) -- AlexDenisov...

We had the same problem with verification when merging/linking 2 modules: a compile unit is not listed in named metadata (llvm.dbg.cu), We worked around this problem by using the DebugInfoFinder processModule function, which identifies all the compile units in the new module, by visiting all the subprogram scopes and the already available compile units. However, this succeeds verification only if the unnamed/missing compile units have children sub programs. This is not a strong guarantee. Anna On De...

...ation in two places (IR verifier and the module pass). The advantage is we can verify more frequently on structures, comparing against doing this in the module pass. > > b) Module pass - > > Walk down from the CUs in the file and verify everything we see. > This is DebugInfoFinder.processModule. > I think then the only duplication we'll get are methods from classes as > the context for functions. We'll also need to check the contexts on the > various metadata operands on the line numbers which is unfortunate as that > probably involves a separate walk over the instru...

...; 7.54% opt opt [.] >>>> llvm::TypeFinder::incorporateValue(llvm::Value const*) >>>> 2.66% opt libc-2.17.so [.] 0x0000000000138c02 >>>> 2.26% opt opt [.] >>>> llvm::SlotTracker::processModule() >>>> >>>> It is surprise that all compile-time for TypeFinder is added into the >>>> compile-time for Polly-detect, but I cannot find the any call instructions >>>> to TypeFinder in Polly-detect. >>> >>>Yes, this does not seem very...

...::TypeFinder::incorporateType(llvm::Type*) >> 7.54% opt opt [.] llvm::TypeFinder::incorporateValue(llvm::Value const*) >> 2.66% opt libc-2.17.so [.] 0x0000000000138c02 >> 2.26% opt opt [.] llvm::SlotTracker::processModule() >> >> It is surprise that all compile-time for TypeFinder is added into the compile-time for Polly-detect, but I cannot find the any call instructions to TypeFinder in Polly-detect. > >Yes, this does not seem very conclusive. We probably need a call graph >to see where those...

...e shared a DITypeMap entry). To get the forced mutation to a type decl to work here, I would somehow need to detect when a composite type on the source module was *not* also used by the original destination module. The only way I came up with off the top of my head was to also do a DebugInfoFinder::processModule on the dest module, and subtract the resulting types() from those I found when finding types on the source module I'm about to import, and only force-convert the remaining ones to type decls. Interested in feedback on any of the above, and in particular on the cleanest way to create type decl...

...pe*) >>> 7.54% opt opt [.] >>> llvm::TypeFinder::incorporateValue(llvm::Value const*) >>> 2.66% opt libc-2.17.so [.] 0x0000000000138c02 >>> 2.26% opt opt [.] >>> llvm::SlotTracker::processModule() >>> >>> It is surprise that all compile-time for TypeFinder is added into the >>> compile-time for Polly-detect, but I cannot find the any call instructions >>> to TypeFinder in Polly-detect. >> >>Yes, this does not seem very conclusive. We probably...

On Sun, Jul 14, 2013 at 10:17 AM, Star Tan <tanmx_star at yeah.net> wrote: > Hi Sebastian, > > Yes, you have pointed an important reason. If we comment this source code > you have listed, then the compile-time overhead for oggenc*8.ll can be > reduced from 40.5261 ( 51.2%) to 20.3100 ( 35.7%). > > I just sent another mail to explain why polly-detect pass leads to >

...> On Dec 23, 2016, at 12:42 PM, Anna Thomas <anna at azul.com> wrote: > > We had the same problem with verification when merging/linking 2 modules: a compile unit is not listed in named metadata (llvm.dbg.cu), > > We worked around this problem by using the DebugInfoFinder processModule function, which identifies all the compile units in the new module, by visiting all the subprogram scopes and the already available compile units. However, this succeeds verification only if the unnamed/missing compile units have children sub programs. This is not a strong guarantee. > > &...

Folks, I am newbie to llvm! I am writing a simple pass that inherits from ModulePass. I override the runOnModule method. In the method, i am attempting to print all the function in the module and the source-file they appear in. I could print the name of the function using the Module::iterator. I am, however, not able to figure-out the way to identify the source-file for a given

...ing some info in LLVM Blog about metadata, in llvm docs about SourceLevel Debugging with LLVM + StripSymbols.cpp, Metadata.cpp, DebugInfo.cpp) I found that I can get it from DebugInfo or Metadata. But my little research was not successful. my code excerpt: DebugInfoFinder DIFinder; DIFinder.processModule(*M); llvm::outs() << "Count of global Variables in Module : " << DIFinder.global_variable_count() << "\n"; for(DIGlobalVariableExpression *DIGVExpr : DIFinder.global_variables()) { if(DIGlobalVariable *DIGV = DIGVExpr->getVariable())...

...entry). To get the forced mutation to a > type decl to work here, I would somehow need to detect when a composite > type on the source module was *not* also used by the original destination > module. The only way I came up with off the top of my head was to also do a > DebugInfoFinder::processModule on the dest module, and subtract the > resulting types() from those I found when finding types on the source > module I'm about to import, and only force-convert the remaining ones to > type decls. > > > > > > Interested in feedback on any of the above, and in particu...

My off the cuff idea here is to make it a module pass, but we'll split the verification a bit: a) IR verification time - Verify debug metadata attached to instructions (i.e. line information). Only check it for structure (i.e. do the various metadata nodes have the right number and kind of operands). b) Module pass - Walk down from the CUs in the file and verify everything we see. I think

...llvm::TypeFinder::incorporateType(llvm::Type*) > 7.54% opt opt [.] > llvm::TypeFinder::incorporateValue(llvm::Value const*) > 2.66% opt libc-2.17.so [.] 0x0000000000138c02 > 2.26% opt opt [.] > llvm::SlotTracker::processModule() > > It is surprise that all compile-time for TypeFinder is added into the > compile-time for Polly-detect, but I cannot find the any call instructions > to TypeFinder in Polly-detect. > > Do you have further suggestion? > You can try to set a breakpoint with gdb on llvm::Typ...

...entry). To get the forced mutation to a > type decl to work here, I would somehow need to detect when a composite > type on the source module was *not* also used by the original destination > module. The only way I came up with off the top of my head was to also do a > DebugInfoFinder::processModule on the dest module, and subtract the > resulting types() from those I found when finding types on the source > module I'm about to import, and only force-convert the remaining ones to > type decls. > > > > > > Interested in feedback on any of the above, and in particu...

Hi all, Currently, debug info verifier is part of the IR verifier which is a function pass. One part of the IR verifier that I don't like is it verifies module-level data in doFinalization. If we have two verifier passes in a single module pass manager, doFinalization of the two passes will run on the same module data after all passes. I followed the same model for debug info verifier:

...::TypeFinder::incorporateType(llvm::Type*) >> 7.54% opt opt [.] llvm::TypeFinder::incorporateValue(llvm::Value const*) >> 2.66% opt libc-2.17.so [.] 0x0000000000138c02 >> 2.26% opt opt [.] llvm::SlotTracker::processModule() >> >> It is surprise that all compile-time for TypeFinder is added into the compile-time for Polly-detect, but I cannot find the any call instructions to TypeFinder in Polly-detect. > >Yes, this does not seem very conclusive. We probably need a call graph >to see where those...