6502/llvm-6502
1
0
Fork 0
mirror of https://github.com/c64scene-ar/llvm-6502.git synced 2024-12-14 11:32:34 +00:00
Code Issues Projects Releases Wiki Activity

Update the profiling section

Browse Source 
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@12243 91177308-0d34-0410-b5e6-96231b3b80d8
This commit is contained in:
Chris Lattner 2004-03-08 22:29:35 +00:00
parent 96ab5caf2d
commit a5422e4048
1 changed files with 22 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

27
docs/OpenProjects.html
View File

@ -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>
<!-- ======================================================================= -->