search for: profileestimator

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

...* 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 context....

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

Hi Chandler, I'm a GSoC student working on profiling support (mentor CC'ed). I'm no stranger to the issues with the current system: my original proposal was written without knowledge of the limitations. This is why this list hasn't heard much from me yet. I would like to continue working on profiling support but I'm not attached to ProfileInfo and wouldn't be

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

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

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

On Sun, Jul 15, 2012 at 8:32 AM, Alastair Murray <alastairmurray42 at gmail.com > wrote: > Hi Chandler, > > I'm a GSoC student working on profiling support (mentor CC'ed). I'm no > stranger to the issues with the current system: my original proposal was > written without knowledge of the limitations. This is why this list > hasn't heard much from me yet.

...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 it i...

Hi Chandler and Alastair, I have been using the Profile.pl and the related passes and optimizations for about 4 years now. With every new release lately, the support for the profile scripts and their framework seemed to be downgrading. Hence, I used my own tiny one line fixes to keep them working. I offered to send these small patches to keep these scripts working, to the LLVM dev so that others

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