[www] r202159 - Remove trailing spaces
Sylvestre Ledru
sylvestre at debian.org
Tue Feb 25 08:17:41 PST 2014
Author: sylvestre
Date: Tue Feb 25 10:17:41 2014
New Revision: 202159
URL: http://llvm.org/viewvc/llvm-project?rev=202159&view=rev
Log:
Remove trailing spaces
Modified:
www/trunk/OpenProjects.html
Modified: www/trunk/OpenProjects.html
URL: http://llvm.org/viewvc/llvm-project/www/trunk/OpenProjects.html?rev=202159&r1=202158&r2=202159&view=diff
==============================================================================
--- www/trunk/OpenProjects.html (original)
+++ www/trunk/OpenProjects.html Tue Feb 25 10:17:41 2014
@@ -74,7 +74,7 @@ LLVM bug tracker</a>. See the <a href="h
see their "Open projects" page:</p>
<ul>
-<li>The <a href="http://clang.llvm.org/OpenProjects.html">Clang Open
+<li>The <a href="http://clang.llvm.org/OpenProjects.html">Clang Open
Projects</a> list.</li>
<li>The <a href="http://vmkit.llvm.org/OpenProjects.html">VMKit Open
Projects</a> list.</li>
@@ -160,10 +160,10 @@ across the board.</p>
<p>
The <a href="http://llvm.org/bugs/">LLVM bug tracker</a> occasionally
has <a
- href="http://llvm.org/bugs/buglist.cgi?short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=code-cleanup&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&changedin=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Bug+Number&field0-0-0=noop&type0-0-0=noop&value0-0-0=">"code-cleanup" bugs</a> filed in it.
-Taking one of these and fixing it is a good way to get your feet wet in the
+ href="http://llvm.org/bugs/buglist.cgi?short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=code-cleanup&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&changedin=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Bug+Number&field0-0-0=noop&type0-0-0=noop&value0-0-0=">"code-cleanup" bugs</a> filed in it.
+Taking one of these and fixing it is a good way to get your feet wet in the
LLVM code and discover how some of its components work. Some of these include
-some major IR redesign work, which is high-impact because it can simplify a lot
+some major IR redesign work, which is high-impact because it can simplify a lot
of things in the optimizer.
</p>
@@ -176,9 +176,9 @@ Some specific ones that would be great t
<li><a href="http://llvm.org/PR11944">Static constructors should be purged from LLVM</a></li>
</ul>
</p>
-
+
<p>Additionally, there are performance improvements in LLVM that need to get
-fixed. These are marked with the <tt>slow-compile</tt> keyword. Use
+fixed. These are marked with the <tt>slow-compile</tt> keyword. Use
<a href="http://llvm.org/bugs/buglist.cgi?short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=slow-compile&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&changedin=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&namedcmd=Bugs+I+Fixed&newqueryname=&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=">this Bugzilla query</a>
to find them.</p>
@@ -199,13 +199,13 @@ us a lot of coverage of programs and ena
problem areas in the compiler.</p>
<p>
-One extremely useful task, which does not require in-depth knowledge of
+One extremely useful task, which does not require in-depth knowledge of
compilers, would be to extend our testsuite to include <a href=
"http://nondot.org/sabre/LLVMNotes/#benchmarks">new programs and benchmarks</a>.
In particular, we are interested in cpu-intensive programs that have few
library dependencies, produce some output that can be used for correctness
-testing, and that are redistributable in source form. Many different programs
-are suitable, for example, see <a
+testing, and that are redistributable in source form. Many different programs
+are suitable, for example, see <a
href="http://nondot.org/sabre/LLVMNotes/#benchmarks">this list</a> for some
potential candidates.
</p>
@@ -306,9 +306,9 @@ from a number of problems where it will
be rewritten from scratch to solve these and other problems.</li>
<li><a href="http://llvm.org/bugs/show_bug.cgi?id=2116">Add support for
transactions to the PassManager</a> for improved bugpoint.</li>
-<li><a href="http://llvm.org/bugs/show_bug.cgi?id=539">Improve bugpoint to
+<li><a href="http://llvm.org/bugs/show_bug.cgi?id=539">Improve bugpoint to
support running tests in parallel on MP machines</a>.</li>
-<li>Add MC assembler/disassembler and JIT support to the SPARC port.</li>
+<li>Add MC assembler/disassembler and JIT support to the SPARC port.</li>
<li>Move more optimizations out of the <tt>-instcombine</tt> pass and into
InstructionSimplify. The optimizations that should be moved are those that
do not create new instructions, for example turning <tt>sub i32 %x, 0</tt>
@@ -343,7 +343,7 @@ also be very rewarding.</p>
improvements to LLVM core</a> are awaiting design and implementation.</p>
<ol>
-<li><a href="http://nondot.org/sabre/LLVMNotes/DebugInfoImprovements.txt">Improvements
+<li><a href="http://nondot.org/sabre/LLVMNotes/DebugInfoImprovements.txt">Improvements
for Debug Information Generation</a></li>
<li><a href="http://llvm.org/PR1269">EH support for non-call exceptions</a></li>
<li>Many ideas for feature requests are stored in LLVM bugzilla. Just <a
@@ -364,16 +364,16 @@ both pointer analysis based optimization
themselves. It seems natural to want to take advantage of this:</p>
<ol>
-<li>The globals mod/ref pass basically does really simple and cheap
-bottom-up context sensitive alias analysis. It being simple and cheap
-are really important, but there are simple things that we could do to
-better capture the effects of functions that access pointer
-arguments. This can be really important for C++ methods, which spend
+<li>The globals mod/ref pass basically does really simple and cheap
+bottom-up context sensitive alias analysis. It being simple and cheap
+are really important, but there are simple things that we could do to
+better capture the effects of functions that access pointer
+arguments. This can be really important for C++ methods, which spend
lots of time accessing pointers off 'this'.</li>
-<li>The alias analysis API supports the getModRefBehavior method, which
-allows the implementation to give details analysis of the functions.
-For example, we could implement <a href="http://llvm.org/PR1604">full knowledge
+<li>The alias analysis API supports the getModRefBehavior method, which
+allows the implementation to give details analysis of the functions.
+For example, we could implement <a href="http://llvm.org/PR1604">full knowledge
of printf/scanf</a> side effects, which would be useful. This feature is in
place but not being used for anything right now.</li>
<li>We need some way to reason about errno. Consider a loop like this:
@@ -391,19 +391,19 @@ place but not being used for anything ri
x += t;
</pre>
-<p>This transformation is safe, because the value of errno isn't
-otherwise changed in the loop and the exit value of errno from the
-loop is the same. We currently can't do this, because sqrt clobbers
-errno, so it isn't "readonly" or "readnone" and we don't have a good
+<p>This transformation is safe, because the value of errno isn't
+otherwise changed in the loop and the exit value of errno from the
+loop is the same. We currently can't do this, because sqrt clobbers
+errno, so it isn't "readonly" or "readnone" and we don't have a good
way to model this.</p>
-<p>The hard part of this project is figuring out how to describe errno
-in the optimizer: each libc #defines errno to something different it
-seems. Maybe the solution is to have a __builtin_errno_addr() or
+<p>The hard part of this project is figuring out how to describe errno
+in the optimizer: each libc #defines errno to something different it
+seems. Maybe the solution is to have a __builtin_errno_addr() or
something and change sys headers to use it.</p>
-<li>There are lots of ways to optimize out and <a
-href="http://llvm.org/PR452">improve handling of
+<li>There are lots of ways to optimize out and <a
+href="http://llvm.org/PR452">improve handling of
memcpy/memset</a>.</li>
</ol>
@@ -481,7 +481,7 @@ link-time optimizations for code size op
<li>Implement a Loop Dependence Analysis Infrastructure<br>
- Design some way to represent and query dep analysis</li>
<li>Value range propagation pass</li>
- <li>More fun with loops:
+ <li>More fun with loops:
<a href="http://www.cs.ualberta.ca/~amaral/cascon/CDP04/tal.html">
Predictive Commoning
</a>
@@ -501,26 +501,26 @@ link-time optimizations for code size op
<div class="www_text">
<ol>
-<li>Merge the delay slot filling logic that is duplicated into (at least)
- the Sparc and Mips backends into a single target independent pass.
- Likewise, the branch shortening logic in several targets should be merged
+<li>Merge the delay slot filling logic that is duplicated into (at least)
+ the Sparc and Mips backends into a single target independent pass.
+ Likewise, the branch shortening logic in several targets should be merged
together into one pass.</li>
<li>Implement 'stack slot coloring' to allocate two frame indexes to the same
stack offset if their live ranges don't overlap. This can reuse a bunch of
analysis machinery from LiveIntervals. Making the stack smaller is good
- for cache use and very important on targets where loads have limited
+ 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. 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
+ 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. Work has started on this, please inquire on llvmdev.</li>
<li>Implement interprocedural register allocation. The CallGraphSCCPass can be
- used to implement a bottom-up analysis that will determine the *actual*
- registers clobbered by a function. Use the pass to fine tune register usage
+ used to implement a bottom-up analysis that will determine the *actual*
+ registers clobbered by a function. Use the pass to fine tune register usage
in callers based on *actual* registers used by the callee.</li>
<li>Add support for 16-bit x86 assembly and real mode to the assembler and
disassembler, for use by BIOS code. This includes both 16-bit instruction
@@ -551,28 +551,28 @@ run it through llvm-gcc, then run a rand
Try to crash <tt><a href="/docs/CommandGuide/html/opt.html">opt</a></tt>. When
<tt>opt</tt> crashes, use <tt><a
href="/docs/CommandGuide/html/bugpoint.html">bugpoint</a></tt> to reduce the
-test case and post it to a website or mailing list. Repeat ad infinitum.</li>
+test case and post it to a website or mailing list. Repeat ad infinitum.</li>
<li>Add sandbox features to the Interpreter: catch invalid memory accesses,
potentially unsafe operations (access via arbitrary memory pointer) etc.
</li>
<li>Port <a href="http://valgrind.org">Valgrind</a> to use LLVM code generation
and optimization passes instead of its own.</li>
<li>Write LLVM IR level debugger (extend Interpreter?)</li>
-<li>Write an LLVM Superoptimizer. It would be interesting to take ideas from
+<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
+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
+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
+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>
More information about the llvm-commits
mailing list