search for: profileestim

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 me) Cheers, Roel

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 Profile...

...* Loop unswitching * Inliner The existing BranchProbabilityInfo, and BlockFrequencyInfo are not used in Transforms/*/* at all, just in CodeGen/*. Is there a reason for this, or is it quite possible to use them in Transforms/*/* passes? The original plan was to test these using ProfileEstimator, now the static heuristics within BranchProbability could be used instead until branch weight metadata is successfully maintained through CFG altering passes. #2 Make the profiler more JIT friendly The ProfileInfo based profiling support is not very friendly towards PGO within a JIT conte...

...sents itself. >> 3. The static profiling estimator should be implemented as just another >> ProfileInfo implementation. I believe this can be a separate patch. Similarly >> the profile verifier is just another consumer of ProfileInfo and can be a >> separate patch. > The ProfileEstimator is already a subclass of ProfileInfo and implements that interface. Yes, these two are easily split into separate patches. Right. One nice benefit of having the ProfileInterface be completely abstract is that it should be straightforward to move the ProfileEstimator to being lazy and only comp...

...hat data once loaded, There is also the llvm-prof tool, but yes: there is only one optimization pass that uses profiling data and it is not on by default. The hindrance to using ProfileInfo in other passes is that almost no passes preserve it and it can not be recalculated (just estimated by ProfileEstimate). As far as I can tell BranchProbability and BlockFrequency would also be invalidated by any CFG altering passes. Preserving ProfileInfo was my primary long-term (post-GSoC) task, preserving BranchProbability and BlockFrequency instead should be no harder. > and has seen > essential...

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 Profile...

Hello folks, I'd like to remove all of the old and defunct profile info passes from LLVM. These have been almost entirely supplanted by the BranchProbability and BlockFrequency systems, which are actually on by default, and in use in optimization passes. The old system is not on, and hasn't been touched in years except to do minor build fixes and updates. As far as I'm aware, the

...t; * Inliner > > The existing BranchProbabilityInfo, and BlockFrequencyInfo are not used > in Transforms/*/* at all, just in CodeGen/*. Is there a reason for > this, or is it quite possible to use them in Transforms/*/* passes? The > original plan was to test these using ProfileEstimator, now the static > heuristics within BranchProbability could be used instead until branch > weight metadata is successfully maintained through CFG altering passes. > > > #2 Make the profiler more JIT friendly > > The ProfileInfo based profiling support is not very frien...

...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 ProfileVe...

...; > There is also the llvm-prof tool, but yes: there is only one > optimization pass that uses profiling data and it is not on by default. > The hindrance to using ProfileInfo in other passes is that almost no > passes preserve it and it can not be recalculated (just estimated by > ProfileEstimate). > > As far as I can tell BranchProbability and BlockFrequency would also be > invalidated by any CFG altering passes. Preserving ProfileInfo was my > primary long-term (post-GSoC) task, preserving BranchProbability and > BlockFrequency instead should be no harder. > Details...

...n passes to update it. Good point. > 3. The static profiling estimator should be implemented as just another > ProfileInfo implementation. I believe this can be a separate patch. Similarly > the profile verifier is just another consumer of ProfileInfo and can be a > separate patch. The ProfileEstimator is already a subclass of ProfileInfo and implements that interface. Yes, these two are easily split into separate patches. > 4. Finally, the new optimal edge instrumentation & ProfileInfo implementation > can be brought in. > > Does this sound like a reasonable plan? Although...

...ith that data once loaded, There is also the llvm-prof tool, but yes: there is only one optimization pass that uses profiling data and it is not on by default. The hindrance to using ProfileInfo in other passes is that almost no passes preserve it and it can not be recalculated (just estimated by ProfileEstimate). As far as I can tell BranchProbability and BlockFrequency would also be invalidated by any CFG altering passes. Preserving ProfileInfo was my primary long-term (post-GSoC) task, preserving BranchProbability and BlockFrequency instead should be no harder. Details for another thread, but esse...

...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) { >...