diff options
author | Chris Lattner <sabre@nondot.org> | 2004-03-08 22:29:35 +0000 |
---|---|---|
committer | Chris Lattner <sabre@nondot.org> | 2004-03-08 22:29:35 +0000 |
commit | a5422e404885650e51fd14f55d5e9636bfcd47f4 (patch) | |
tree | 3343a9685bdeead878e6e79544b4453884516dd4 /docs/OpenProjects.html | |
parent | 96ab5caf2db23939c21c36d9468fa6c95e23129d (diff) |
Update the profiling section
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@12243 91177308-0d34-0410-b5e6-96231b3b80d8
Diffstat (limited to 'docs/OpenProjects.html')
-rw-r--r-- | docs/OpenProjects.html | 27 |
1 files changed, 22 insertions, 5 deletions
diff --git a/docs/OpenProjects.html b/docs/OpenProjects.html index 1a70dc8405..d528bf3e76 100644 --- a/docs/OpenProjects.html +++ b/docs/OpenProjects.html @@ -229,11 +229,11 @@ themselves. It seems natural to want to take advantage of this...</p> <div class="doc_text"> -<p>We are getting to the point where we really need a unified infrastructure for -profile guided optimizations. It would be wonderful to be able to write profile -guided transformations which can be performed either at static compile time -(compile time or offline optimization time) or at runtime in a JIT type setup. -The LLVM transformation itself shouldn't need to know how it is being used.</p> +<p>We now have a unified infrastructure for writing profile-guided +transformations, which will work either at offline-compile-time or in the JIT, +but we don't have many transformations. We would welcome new profile-guided +transformations as well as improvements to the current profiling system. +</p> <p>Ideas for profile guided transformations:</p> @@ -245,6 +245,23 @@ The LLVM transformation itself shouldn't need to know how it is being used.</p> <li>...</li> </ol> +<p>Improvements to the existing support:</p> + +<ol> +<li>The current block and edge profiling code that gets inserted is very simple +and inefficient. Through the use of control-dependence information, many fewer +counters could be inserted into the code. Also, if the execution count of a +loop is known to be a compile-time or runtime constant, all of the counters in +the loop could be avoided.</li> + +<li>You could implement one of the "static profiling" algorithms which analyze a +piece of code an make educated guesses about the relative execution frequencies +of various parts of the code.</li> + +<li>You could add path profiling support, or adapt the existing LLVM path +profiling code to work with the generic profiling interfaces.</li> +</ol> + </div> <!-- ======================================================================= --> |