search for: typefinder

...ry useful suggestion. >> I have profiled the oggenc*16 and oggenc*32 and the results are listed as follows: >> >> oggenc*16: polly-detect compile-time percentage is 71.3%. The top five functions reported by perf are: >> 48.97% opt opt [.] llvm::TypeFinder::run(llvm::Module const&, bool) >> 7.43% opt opt [.] llvm::TypeFinder::incorporateType(llvm::Type*) >> 7.36% opt opt [.] llvm::TypeFinder::incorporateValue(llvm::Value const*) >> 4.04% opt libc-2.17.so...

...oggenc*16 and oggenc*32 and the results are listed as >>> follows: >>> >>> oggenc*16: polly-detect compile-time percentage is 71.3%. The top five >>> functions reported by perf are: >>> 48.97% opt opt [.] >>> llvm::TypeFinder::run(llvm::Module const&, bool) >>> 7.43% opt opt [.] >>> llvm::TypeFinder::incorporateType(llvm::Type*) >>> 7.36% opt opt [.] >>> llvm::TypeFinder::incorporateValue(llvm::Value const*) >&gt...

...ry useful suggestion. >> I have profiled the oggenc*16 and oggenc*32 and the results are listed as follows: >> >> oggenc*16: polly-detect compile-time percentage is 71.3%. The top five functions reported by perf are: >> 48.97% opt opt [.] llvm::TypeFinder::run(llvm::Module const&, bool) >> 7.43% opt opt [.] llvm::TypeFinder::incorporateType(llvm::Type*) >> 7.36% opt opt [.] llvm::TypeFinder::incorporateValue(llvm::Value const*) >> 4.04% opt libc-2.17.so...

...very useful suggestion. > I have profiled the oggenc*16 and oggenc*32 and the results are listed as > follows: > > oggenc*16: polly-detect compile-time percentage is 71.3%. The top five > functions reported by perf are: > 48.97% opt opt [.] > llvm::TypeFinder::run(llvm::Module const&, bool) > 7.43% opt opt [.] > llvm::TypeFinder::incorporateType(llvm::Type*) > 7.36% opt opt [.] > llvm::TypeFinder::incorporateValue(llvm::Value const*) > 4.04% opt libc-2.17.so...

...and the results are listed as >>>> follows: >>>> >>>> oggenc*16: polly-detect compile-time percentage is 71.3%. The top five >>>> functions reported by perf are: >>>> 48.97% opt opt [.] >>>> llvm::TypeFinder::run(llvm::Module const&, bool) >>>> 7.43% opt opt [.] >>>> llvm::TypeFinder::incorporateType(llvm::Type*) >>>> 7.36% opt opt [.] >>>> llvm::TypeFinder::incorporateValue(llvm::Value...

Hi all, I 'd like to fetch a list of structures, and found that it could be done via LLVMContextImpl *pImpl = Context.pImpl; pImpl->AnonStructTypes This however needs the inclusion of LLVMContextImpl.h, which is not contained in the includes dir, but in the lib/IR dir (next to the .cpp files) and is not installed under /usr/local/include... Whats the reason for this? Isn't it

Hey All, Totem has stopped playing .wmv files recently. I don't know exactly when this happened, but I know I've played .wmv files not too very long ago. I've got 372 .wmv files all of which I've played at one time. When I try to launch any one of the .wmv files from file manager totem pops up but the controls are not functional. If I start totem from a terminal there is no

...elf and can verify that for oggenc 16x, your patch reduces the scop-detection time from 90 seconds (80 %) to 0.5 seconds (2.5 %). I think there are two problems: 1) The cost of printing a single LLVM type/value increases with the size of the overall Module. This seems to be because TypeFinder::run() is called each time, without caching in place. The cost of TypeFinder::run() increases with the size of the module, as it basically just performs a scan on the entire Module. 2) We are formatting the failure messages during normal compilation, even though they are only...

On Dec 12, 2010, at 12:52 PM, Anton Korobeynikov wrote: >> Very true, but we do want the testsuite to run fast. Can it be sped up? > Can't we just run testsuite with asm-verbose=0 ? I meant llvm/test. I'm just surprised it is that slow, what is costing all the time? -Chris

...elf self total time seconds seconds calls s/call s/call name 33.67 17.19 17.19 849 0.02 0.04 AddModuleTypesToPrinter 17.51 26.13 8.94 265849169 0.00 0.00 llvm::Value::getType() 8.74 30.59 4.46 258948922 0.00 0.00 ::TypeFinder::IncorporateType 3.25 32.25 1.66 5242575 0.00 0.00 ::TypeFinder::IncorporateValue - David Meyer -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20101212/7248a41d/attachment.html>

...t; I want to create a database of all structures (global and local) > defined and being used in my program. Eg. < A , <int32, int32> , B , > <int32, bool , char *>>. I think the closest LLVM has is either Module::getIdentifiedStructTypes or the class it actually uses: "TypeFinder". Beware though, struct types may not have a name, and even if they do it won't necessarily correspond to the original C or C++ name in any meaningful way. These both return an std::vector<StructType *> in some form, which you can probe for the fields (they'll definitely be unna...

On 07/21/2013 09:49 AM, Star Tan wrote: > Hi all, > > > I have attached a patch file to reduce the polly-detect overhead. Great. > My idea is to avoid calling TypeFinder in Non-DEBUG mode, so > TypeFinder is only called in DEBUG mode with the DEBUG macro. This > patch file did this work with following modifications: > > > First, it keeps most of string information by replacing "<<" with "+" operation. For example, code lik...

Hi all, I have attached a patch file to reduce the polly-detect overhead. My idea is to avoid calling TypeFinder in Non-DEBUG mode, so TypeFinder is only called in DEBUG mode with the DEBUG macro. This patch file did this work with following modifications: First, it keeps most of string information by replacing "<<" with "+" operation. For example, code like this: INVALID(CFG...

LLVM Newbie here. I have the following C++ program using namespace std; struct A{ int i; int j; }; int main() { struct A obj; obj.i = 10; obj.j = obj.i; return 0; } Using clang++, I can see that LLVM IR contains struct field as below %struct.A = type { i32, i32 } I would like to obtain the structure elements using LLVM Pass. I write the following program - that iterates

At 2013-07-22 01:40:31,"Tobias Grosser" <tobias at grosser.es> wrote: >On 07/21/2013 09:49 AM, Star Tan wrote: >> Hi all, >> >> >> I have attached a patch file to reduce the polly-detect overhead. > >Great. > >> My idea is to avoid calling TypeFinder in Non-DEBUG mode, so >> TypeFinder is only called in DEBUG mode with the DEBUG macro. This >> patch file did this work with following modifications: >> >> >> First, it keeps most of string information by replacing "<<" with "+" operation. F...

...ype*>::ret_type llvm::cast<llvm::PointerType, > llvm::Type>(Val=0x0000000000000000) at Casting.h:255 > frame #9: 0x000000010047227d > dump`llvm::GlobalValue::getType(this=0x00000001013ffff6) const at > GlobalValue.h:265 > frame #10: 0x00000001004bad34 > dump`llvm::TypeFinder::run(this=0x00007ffeefbff530, M=0x0000000101401e80, > onlyNamed=false) at TypeFinder.cpp:38 > frame #11: 0x00000001001a97c9 dump`(anonymous > namespace)::TypePrinting::incorporateTypes(this=0x00007ffeefbff530, > M=0x0000000101401e80) at AsmWriter.cpp:491 > frame #12: 0x000000...

...PATCH] ScopDetect: Optimize compile-time cost for log string > operations. > > String operatioins resulted by raw_string_ostream in the INVALID macro can lead > to significant compile-time overhead when compiling large size source code. > This is because raw_string_ostream relies on TypeFinder class, whose > compile-time cost increases as the size of the module increases. This patch > targets to avoid calling TypeFinder in normal case, so TypeFinder class is only > called in DEBUG mode with DEBUG macro or in PollyView mode. > > With this patch file, the relative compile-ti...

...er" <tobias at grosser.es> wrote: > >> On 07/21/2013 09:49 AM, Star Tan wrote: >>> Hi all, >>> >>> >>> I have attached a patch file to reduce the polly-detect overhead. >> >> Great. >> >>> My idea is to avoid calling TypeFinder in Non-DEBUG mode, so >>> TypeFinder is only called in DEBUG mode with the DEBUG macro. This >>> patch file did this work with following modifications: >>> >>> >>> First, it keeps most of string information by replacing "<<" with "...

...::Module (linked module with lots of types/...). I started with plain ::print and switched over to http://llvm.org/docs/doxygen/html/classllvm_1_1Value.html#a04e6fc765eeb0c4c90ac5d55113db116 with a ModuleSlotTracker I pass in myself to avoid some complexity. Still now I have the issue that the TypeFinder::run and related that is done internally by each print still is 99% of my program runtime. (at least perf tells me that) Is there any clever workaround for this? I looked a bit through the sources but it seems that no API is exported that would allow a faster print call. Given I want the output...

Hello, I'm updating a legacy code using LLVM 2.5 where it has an iteration through a Module's TypeSymbolTable to process each StructType. In LLVM 3.4, TypeSymbolTable has been removed. I can only find the LLVMContextImpl instance of a Module's LLVMContext which has AnonStructTypes and NamedStructTypes two maps. However, LLVMContextImpl is an opaque class which cannot be directly