search for: profileestimate

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

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 ProfileVerifierPass. This is what

Hi all, In light of the expected removal of ProfileInfo this is a request for comments on the next few items that I now plan to work on for GSoC. Planned tasks: #0 Add support for determining branch weight metadata by profiling At the absolute minimum this will require writing a new profile loader which will set branch weight metadata based on profiling data. #1 Optionally use profiling

On Wed, Jul 1, 2009 at 2:36 AM, Andreas Neustifter<e0325716 at student.tuwien.ac.at> wrote: >> [...] >> >> 1. The intent of ProfileInfo is that it is the public interface used by the rest >> of LLVM for all "profiling" related analyses. As such, we want it to have a >> thin, well-defined interface which can be implemented by multiple analysis >>

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

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 ProfileVerifierPass. This is what

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

Hi Alastair, In addition to your planned tasks, you might want to put in some work to ensure branch probabilities are not lost during optimization. One known issue is LLVM optimizer can turn branchy code into switch statements and it would completely discard probability. Here is a simple example: static void func2(int N, const int *a, const int *b, int *c) __attribute__((always_inline)); void

Hi all, as proposed in http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-February/020396.html I implemented the algorithm presented in [Ball94]. It only instruments the minimal number of edges necessary for edge profiling. The main changes introduced by this patch are: *) a interface compatible rewrite of ProfileInfo *) a cleanup of ProfileInfoLoader (some functionality in ProfileInfoLoader

...; > 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 fo...

Hi Daniel, Daniel Dunbar wrote: > Hi Andreas, > > First, thanks again for undertaking this work and submitting it back. There is a > lot of good stuff here and it would be great to see it get back into the tree. Thanks for taking the time to review this, I know its a huge patch. I still have a few questions on how you would like this patch to be re-factored and split up. > [...]

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

Hi Andreas, First, thanks again for undertaking this work and submitting it back. There is a lot of good stuff here and it would be great to see it get back into the tree. I have a few major high-level comments on the patch. First off, the patch is quite large and should be broken down into separate incremental changes which are easier to review and apply. I think the patches should more or less