[www] r333355 - Tidy up some language and reword a few projects for clarity.
Eric Christopher via llvm-commits
llvm-commits at lists.llvm.org
Sun May 27 02:48:11 PDT 2018
Author: echristo
Date: Sun May 27 02:48:11 2018
New Revision: 333355
URL: http://llvm.org/viewvc/llvm-project?rev=333355&view=rev
Log:
Tidy up some language and reword a few projects for clarity.
Modified:
www/trunk/OpenProjects.html
Modified: www/trunk/OpenProjects.html
URL: http://llvm.org/viewvc/llvm-project/www/trunk/OpenProjects.html?rev=333355&r1=333354&r2=333355&view=diff
==============================================================================
--- www/trunk/OpenProjects.html (original)
+++ www/trunk/OpenProjects.html Sun May 27 02:48:11 2018
@@ -127,13 +127,13 @@
<p>
Welcome prospective Google Summer of Code 2018 Students! This document is your
starting point to finding interesting and important projects for LLVM, Clang,
-and other related sub-projects. This list of projects is not just developed for
+and other related sub-projects. This list of projects is not only developed for
Google Summer of Code, but open projects that really need developers to work on
and are very beneficial for the LLVM community. </p>
<p>We encourage you to look through this list and see which projects excite you
and match well with your skill set. We also invite proposals not on this
-list. However, you must propose your idea to the LLVM community through our
+list. You must propose your idea to the LLVM community through our
developers' mailing list (llvm-dev at lists.llvm.org or specific subproject mailing
list). Feedback from the community is a requirement for your proposal to be
considered and hopefully accepted.
@@ -203,7 +203,7 @@ main <a href="https://developers.google.
<!-- *********************************************************************** -->
<div class="www_text">
- <p><b>Description of the project:</b> The llvm project has a lot of tools that can be used to inspect binaries, just as any other toolchain project does. However, many people are accustomed to existing tools and so having a command line compatible shell and we'd like to make that easy for them. Bonus points for producing similar output so that automated tools can continue to work reliably.
+ <p><b>Description of the project:</b> The llvm project has a lot of tools that can be used to inspect binaries, as any other toolchain project does. Many people are accustomed to existing tools and so having a command line compatible shell and we'd like to make that easy for them. Bonus points for producing similar output so that automated tools can continue to work reliably.
<p><b>Expected Results:</b>This project has one goal - produce binary tools that are drop in compatible with GNU binutils. The student will be expected to focus on a single tool at a time so that we can count each one as "done" as much as possible.
<p><b>Confirmed Mentor:</b> Eric Christopher and Sterling Augustine</p>
@@ -636,7 +636,7 @@ accepted and completed projects, please
functions.</li></ul>
<ul><li>Allow the representation to deduce successors of a basic block in
common cases</li></ul>
- <ul><li>Allow symbolic names instead of just numbers for virtual
+ <ul><li>Allow symbolic names instead of only numbers for virtual
registers</li></ul>
<ul><li>Helper passes: Strip IR information, rename blocks and values,
debug information, ...</li></ul>
@@ -938,11 +938,11 @@ accepted and completed projects, please
has been integrated in the LLVM build system for ELF. Ideally a
motivated student would do the benchmarking/analysis before the GSoC
starts to familiarize with the problem.</li>
- <li>The meat: Use/extend profile informations generated by LLVM to help
- the linker laying out functions. An obvious way (what gcc uses, [1])
+ <li>The meat: Use/extend profile information generated by LLVM to help
+ the linker lay out functions. An example way (what gcc uses, [1])
is to pass values to the linker using special `.note` sections. The
linker then can reconstruct the call graph and apply an algorithm
- like the one described in [2] (this is just a starting point, other
+ like the one described in [2] (this is a starting point, other
alternatives can be explored).</li>
</ul>
</p>
@@ -1116,13 +1116,12 @@ different and served disparate purposes.
more features had to be shared between the two so that the compiler would behave
properly. An example is when targets have default features on speficic configurations
that don't have flags for. If the back-end has a different "default" behaviour
-than the front-end and the latter has no way of enforcing behaviour, it simply
+than the front-end and the latter has no way of enforcing behaviour, it
won't work.</p>
-<p>Of course, an alternative would be to create flags for all little quirks, but
-first, Clang is not the only front-end or tool that uses LLVM's middle/back ends,
-and second, that's what "default behaviour" is there for, so we'd be missing the
-point.</p>
+<p>An alternative would be to create flags for all little quirks, but first, Clang
+is not the only front-end or tool that uses LLVM's middle/back ends, and second,
+that's what "default behaviour" is there for, so we'd be missing the point.</p>
<p>Several ideas have been floating around to fix the Clang driver WRT recognizing
architectures, features and so on (table-gen it, user-specific configuration files,
@@ -1245,7 +1244,7 @@ all the back-ends: CBE, llc, and lli.</p
<p>Find benchmarks either using our <a
href="http://llvm.org/nightlytest/">test results</a> or on your own,
-where LLVM code generators do not produce optimal code or simply where another
+where LLVM code generators do not produce optimal code or where another
compiler produces better code. Try to minimize the test case that demonstrates
the issue. Then, either <a href="http://bugs.llvm.org/">submit a
bug</a> with your testcase and the code that LLVM produces vs. the code that it
@@ -1315,7 +1314,7 @@ what architecture is covered.</p>
in a searchable database, like LNT</li>
</ul>
-<p>Another idea is to enable the test suite to run all built backends, not just
+<p>Another idea is to enable the test suite to run all built backends, not only
the host architecture, so that coverage report can be built in a fast machine
and have one report per commit without needing to update the buildbots.</p>
@@ -1375,8 +1374,8 @@ improvements to LLVM core</a> are awaiti
<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
- href="http://bugs.llvm.org/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=new-feature&bug_status=UNCONFIRMED&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=All+PRs&newqueryname=&order=Bug+Number&field0-0-0=noop&type0-0-0=noop&value0-0-0=">search for bugs with a "new-feature" keyword</a>.</li>
+<li>Many ideas for feature requests are stored in LLVM bugzilla. Search<a
+ href="http://bugs.llvm.org/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=new-feature&bug_status=UNCONFIRMED&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=All+PRs&newqueryname=&order=Bug+Number&field0-0-0=noop&type0-0-0=noop&value0-0-0=">for bugs with a "new-feature" keyword</a>.</li>
</ol>
</div>
@@ -1390,21 +1389,21 @@ for Debug Information Generation</a></li
<p>We have a <a href="docs/AliasAnalysis.html">strong base for development</a> of
both pointer analysis based optimizations as well as pointer analyses
-themselves. It seems natural to want to take advantage of this:</p>
+themselves. We 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
-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
-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>The globals mod/ref pass does an inexpensive bottom-up context sensitive
+ alias analysis. There are some inexpensive 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 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:
<pre>
@@ -1426,9 +1425,9 @@ loop is the same. We currently can't do
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 important 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
@@ -1553,7 +1552,7 @@ link-time optimizations for code size op
<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
+ 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 llvm-dev.</li>
<li>Implement interprocedural register allocation. The CallGraphSCCPass can be
@@ -1642,7 +1641,7 @@ dependency graph.</li>
<div class="www_text">
<p>
At least one project (and probably more) needs to use analysis information
- (such as call graph analysis) from within a MachineFunctionPass. However,
+ (such as call graph analysis) from within a MachineFunctionPass, however,
most analysis passes operate at the LLVM IR level. In some cases, a value
(e.g., a function pointer) cannot be mapped from the MachineInstr level back
to the LLVM IR level reliably, making the use of existing LLVM analysis
More information about the llvm-commits
mailing list