search for: profileestimatorpass

...h of changes in the area of the Profiling Infrastructure I would like to ask humbly if it is possible to have approve-after-commit permission for the following files: include/llvm/Analysis/ProfileInfo.h include/llvm/Analysis/ProfileInfoLoader.h include/llvm/Analysis/ProfileInfoTypes.h lib/Analysis/ProfileEstimatorPass.cpp lib/Analysis/ProfileInfo.cpp lib/Analysis/ProfileInfoLoader.cpp lib/Analysis/ProfileInfoLoaderPass.cpp lib/Transforms/Instrumentation/* runtime/libprofile/* Also I would have to add some modules (new files) in Analysis, Transforms/Instrumentation and libprofile. This would allow me to make th...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! Andreas Neustifter wrote: > Daniel Dunbar wrote: >> Thanks, applied as r78247. Next? :) > > Oh my, first he is lagging and now it's all a hurry :-) > > Okay, here comes the next one. > > I'm taking a short vacation next week so I will try to prepare 1 or 2 of > the next patches so that you can work on them

Hi, I have a problem with the following scenario: I use the ProfileEstimatorPass to get ProfileInfo and verifiy this info with the ProfileVerifierPass. (Please bear with me, its not about the profiling but about the Pass interaction.) Then the LowerSetJumpPass is executed and I want to verify that the esimtated ProfileInfo survives this pass by calling again the ProfileVerifier...

...deleted: lib/Analysis/PathNumbering.cpp # deleted: lib/Analysis/PathProfileInfo.cpp # deleted: lib/Analysis/PathProfileVerifier.cpp # deleted: lib/Analysis/ProfileDataLoader.cpp # deleted: lib/Analysis/ProfileDataLoaderPass.cpp # deleted: lib/Analysis/ProfileEstimatorPass.cpp # deleted: lib/Analysis/ProfileInfo.cpp # deleted: lib/Analysis/ProfileInfoLoader.cpp # deleted: lib/Analysis/ProfileInfoLoaderPass.cpp # deleted: lib/Analysis/ProfileVerifierPass.cpp # deleted: lib/Transforms/Instrumentation/EdgeProfiling.cpp #...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Daniel Dunbar wrote: > Thanks, applied as r78247. Next? :) Oh my, first he is lagging and now it's all a hurry :-) Okay, here comes the next one. I'm taking a short vacation next week so I will try to prepare 1 or 2 of the next patches so that you can work on them as you have time. Greetings, Andi - --

...eInfoLoader now really only performs the loading but not the post-processing) *) a new instrumentation pass that performs the optimal edge profiling instrumentation *) a helper module MaximumSpanningTree that selects the edges with have to be instrumented for optimal edge profiling *) a ProfileEstimatorPass that does an offline estimation of a profile based on branching and loop depth (also proposed in [Ball94]) (it is possible to use this ProfileEstimator stand-alone to have at least some profile estimation available in the frontend without doing profiling runs) *) a ProfileVerifierPa...

...return 0; > + } > +} This routine is only used in one place, and its result is compared against 0. I think it should be removed and the code should just check (succ_begin(BB) == succ_end(BB)), or for better readability add a succ_empty to CFG.h and use that. > --- llvm-van/lib/Analysis/ProfileEstimatorPass.cpp 1970-01-01 01:00:00.000000000 +0100 > +++ llvm-c7/lib/Analysis/ProfileEstimatorPass.cpp 2009-06-26 16:47:01.000000000 +0200 ... > +bool OptimalEdgeProfiler::runOnModule(Module &M) { > + Function *Main = M.getFunction("main"); > + if (Main == 0) { > + cer...

Hi, I have a problem with the following scenario: I use the ProfileEstimatorPass to get ProfileInfo and verifiy this info with the ProfileVerifierPass. (Please bear with me, its not about the profiling but about the Pass interaction.) Then the LowerSetJumpPass is executed and I want to verify that the esimtated ProfileInfo survives this pass by calling again the ProfileVerifier...

Hello all, I was trying to use the profile estimator and ran into the following issue. An initial weight is assigned to a function entry in lib/Analysis/ProfileEstimator.cpp on line 340. In the code this weight is pow(2.0, 32.0) whereas the comment three lines up explains that this should be 1.0 Can someone fix this in trunk? (replacing 'pow(2.0, 32.0)' with '1.0' worked for

...PathNumbering.cpp > # deleted: lib/Analysis/PathProfileInfo.cpp > # deleted: lib/Analysis/PathProfileVerifier.cpp > # deleted: lib/Analysis/ProfileDataLoader.cpp > # deleted: lib/Analysis/ProfileDataLoaderPass.cpp > # deleted: lib/Analysis/ProfileEstimatorPass.cpp > # deleted: lib/Analysis/ProfileInfo.cpp > # deleted: lib/Analysis/ProfileInfoLoader.cpp > # deleted: lib/Analysis/ProfileInfoLoaderPass.cpp > # deleted: lib/Analysis/ProfileVerifierPass.cpp > # deleted: lib/Transforms/Instrumentation...

...gt; > This routine is only used in one place, and its result is compared against 0. I > think it should be removed and the code should just check (succ_begin(BB) == > succ_end(BB)), or for better readability add a succ_empty to CFG.h and use that. Okay. >> --- llvm-van/lib/Analysis/ProfileEstimatorPass.cpp 1970-01-01 01:00:00.000000000 +0100 >> +++ llvm-c7/lib/Analysis/ProfileEstimatorPass.cpp 2009-06-26 16:47:01.000000000 +0200 > ... >> +bool OptimalEdgeProfiler::runOnModule(Module &M) { >> + Function *Main = M.getFunction("main"); >> + if (Main...