[llvm-commits] CVS: llvm-www/OpenProjects.html

[Chris Lattner]

Changes in directory llvm-www:

OpenProjects.html updated: 1.56 -> 1.57
---
Log message:

update a few entries, add super optimizer idea from John.


---
Diffs of the changes:  (+20 -28)

 OpenProjects.html |   48 ++++++++++++++++++++----------------------------
 1 files changed, 20 insertions(+), 28 deletions(-)


Index: llvm-www/OpenProjects.html
diff -u llvm-www/OpenProjects.html:1.56 llvm-www/OpenProjects.html:1.57
--- llvm-www/OpenProjects.html:1.56	Wed Nov 11 00:41:50 2009
+++ llvm-www/OpenProjects.html	Wed Dec 16 03:03:23 2009
@@ -22,7 +22,6 @@
     <li><a href="#compaction">Code Compaction</a></li>
     <li><a href="#xforms">New Transformations and Analyses</a></li>
     <li><a href="#codegen">Code Generator Improvements</a></li>
-    <li><a href="#objectfiles">Emit objects directly</a></li>
     <li><a href="#misc_new">Miscellaneous Additions</a></li>
   </ol></li>
 </ul>
@@ -409,19 +408,15 @@
     analysis machinery from LiveIntervals.  Making the stack smaller is good
     for cache use and very important on targets where loads have limited 
     displacement like ppc, thumb, mips, sparc, etc.  This should be done as
-    a pass before prolog epilog insertion.</li>
+    a pass before prolog epilog insertion.  This is now done for register
+    allocator temporaries, but not for allocas.</li>
 <li>Implement 'shrink wrapping', which is the intelligent placement of callee
     saved register save/restores.  Right now PrologEpilogInsertion always saves
     every (modified) callee save reg in the prolog and restores it in the 
     epilog.  However, some paths through a function (e.g. an early exit) may 
     not use all regs.  Sinking the save down the CFG avoids useless work on
-    these paths.</li>
+    these paths. Work has started on this, please inquire on llvmdev.</li>
 <li>Rename ISD::BIT_CONVERT to ISD::BITCAST to match the llvm ir concept</li>
-<li>Change the VECTOR_SHUFFLE to be variadic.  Right now, a VECTOR_SHUFFLE 
-    takes three operands: two vectors and a shuffle mask.  The shuffle mask is
-    required to be a BUILD_VECTOR node of N indices.  It would be much better
-    (for several reasons) to eliminate the BUILD_VECTOR and make VECTOR_SHUFFLE
-    take 2+N operands instead.</li>
 <li>Finish adapting existing targets to use the calling convention description
     mechanism (see lib/Target/X86/X86CallingConv.td for an example).</li>
 <li>Implement interprocedural register allocation. The CallGraphSCCPass can be
@@ -431,25 +426,6 @@
 <li>Implement a <a href="http://llvm.org/bugs/show_bug.cgi?id=408">verifier for 
     codegen level instructions</a>.  To help track down malformed machineinstrs 
     sooner and make debugging problems easier.</li>
-<li>Write a new backend for a target 
-    (VAX, i960, PA-RISC,
-     <a href="http://www-cs-faculty.stanford.edu/~knuth/mmix.html">MMIX</a>?)</li>
-</ol>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="www_sectiontitle">
-  <a name="objectfiles">Emit object files directly</a>
-</div>
-
-<div class="www_text">
-
-<ol>
-<li>Implement MachOWriter and ELFWriter to allow LLVM-based compilers to
-    bypass an external assembler.</li>
-<li>Implement an assembler for inline assembly.  Reuse the tablegen files
-    from each backend.</li>
 </ol>
 
 </div>
@@ -486,6 +462,22 @@
   for gcc compiled code.
 </li>
 <li>Write LLVM IR level debugger (extend Interpreter?)</li>
+<li>Write an LLVM Superoptimizer.  It would be interesting to take ideas from 
+    this superoptimizer for x86:
+<a href="http://theory.stanford.edu/~aiken/publications/papers/asplos06.pdf">paper #1</a> and <a href="http://theory.stanford.edu/~sbansal/superoptimizer.html">paper #2</a> and adapt them to run on LLVM code.<p>
+
+It would seem that operating on LLVM code would save a lot of time 
+because its semantics are much simpler than x86.  The cost of operating 
+on LLVM is that target-specific tricks would be missed.<p>
+
+The outcome would be a new LLVM pass that subsumes at least the 
+instruction combiner, and probably a few other passes as well.  Benefits 
+would include not missing cases missed by the current combiner and also 
+more easily adapting to changes in the LLVM IR.<p>
+
+All previous superoptimizers have worked on linear sequences of code. 
+It would seem much better to operate on small subgraphs of the program 
+dependency graph.</li>
 </ol>
 
 </div>
@@ -500,7 +492,7 @@
   src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!"></a>
 
   <a href="http://llvm.org">LLVM Compiler Infrastructure</a><br>
-  Last modified: $Date: 2009/11/11 06:41:50 $
+  Last modified: $Date: 2009/12/16 09:03:23 $
 </address>
 
 <!--#include virtual="footer.incl" -->