search for: profileestim

Displaying 13 results from an estimated 13 matches for "profileestim".

2012 Dec 12
1
[LLVMdev] ProfileEstimator inconsistency
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
2009 Sep 16
1
[LLVMdev] FunctionPass Analysis is not saved after ModulePasses run?
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...
2012 Jul 16
2
[LLVMdev] RFC: Profiling Enhancements (GSoC)
...* 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...
2009 Jul 02
0
[LLVMdev] Profiling in LLVM Patch
...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...
2012 Jul 15
0
[LLVMdev] FYI: Planning to remove ProfileInfo and related passes from LLVM
...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...
2009 Sep 16
0
[LLVMdev] FunctionPass Analysis is not saved after ModulePasses run?
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...
2012 Jul 15
4
[LLVMdev] FYI: Planning to remove ProfileInfo and related passes from LLVM
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
2012 Jul 17
0
[LLVMdev] RFC: Profiling Enhancements (GSoC)
...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...
2009 Jun 29
7
[LLVMdev] Profiling in LLVM Patch
...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...
2012 Jul 15
3
[LLVMdev] FYI: Planning to remove ProfileInfo and related passes from LLVM
...; > 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...
2009 Jul 01
12
[LLVMdev] Profiling in LLVM Patch
...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...
2012 Jul 16
0
[LLVMdev] FYI: Planning to remove ProfileInfo and related passes from LLVM
...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...
2009 Jul 01
0
[LLVMdev] Profiling in LLVM Patch
...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) { >...