This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

[wwwdocs patch] adding a table of contents to the projects file


Hi!

I have added a table of contents to the projects/index.html file. 
When doing this I changed some <li>s to be <h[23]>, so that they
appear in the TOC.
It makes it much more readable now.


I also added a new section for "Work in progress" and added pointers
for some stuff that I saw on the mailing list that is going on. 
Please add some more to that list. 

The labels for the TOC are automatically generated by html-toc.el, I
will change them to something more readable once it's decided that
the proposed structure is acceptable.

The patch:



Index: index.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/projects/index.html,v
retrieving revision 1.12
diff -c -r1.12 index.html
*** index.html	2001/02/10 21:04:44	1.12
--- index.html	2001/03/21 19:19:17
***************
*** 4,33 ****
  <title>GCC Projects</title>
  </head>
  
! <body>
  <h1 align=center>GCC Projects</h1>
  
  <p>You can investigate bugs in our <a href="../gnats.html">GNATS
  database</a> and attempt to fix them or see whether they still are
  present in current GCC.
  
  <p>If you are new to GCC, start with our <a
  href="beginner.html">projects for beginners</a>.
- 
- <p>There is a separate page for <a
- href="bp/main.html">Bounds Checking with Bounded Pointers</a>.
  
  <p>There is a separate project list for the <a
  href="cpplib.html">C preprocessor</a>.
  
  <p>There is a separate projects list for the <a href="web.html">web
  pages</a>.</p>
  
  <p>We also have a page detailing <a href="optimize.html">optimizer
  inadequacies</a>, if you'd prefer to think about it in terms of problems
! instead of features.
  
! <h2>Changes to support C99 standard</h2>
  
  <p>The new version of the C standard (ISO/IEC 9899:1999) requires a
  number of library changes; these have to be provided by the C library,
--- 4,132 ----
  <title>GCC Projects</title>
  </head>
  
! <body><!-- table of contents start -->
! <H1><A NAME="toc">Table of Contents</H1>
! <UL>
! <LI><A HREF="#tocref1">Fix bugs in the GNATS database</A>
! <LI><A HREF="#tocref2">Projects for beginner GCC hackers</A>
! <LI><A HREF="#tocref3">Projects for the C preprocessor</A>
! <LI><A HREF="#tocref4">Projects for the GCC web pages</A>
! <LI><A HREF="#tocref5">Work in progress</A>
! <UL>
! <LI><A HREF="#tocref6">Bounds Checking with Bounded Pointers</A>
! <LI><A HREF="#tocref7">New register allocator</A>
! <LI><A HREF="#tocref8">SSA for trees</A>
! <LI><A HREF="#tocref9">Value range propagation pass</A>
! </UL>
! <LI><A HREF="#tocref10">Optimizer inadequacies</A>
! <LI><A HREF="#tocref11">Changes to support C99 standard</A>
! <LI><A HREF="#tocref12">Improve the Haifa scheduler</A>
! <LI><A HREF="#tocref13">Improvements to global cse and partial redundancy elimination:</A>
! <LI><A HREF="#tocref14">Miscellaneous ideas:</A>
! <UL>
! <LI><A HREF="#tocref15">Chill should use garbage collection</A>
! <LI><A HREF="#tocref16">Improve <code>-Wconversion</code></A>
! <LI><A HREF="#tocref17">Implement various builtin functions for ISO C99's 
! <code>&lt;tgmath.h&gt;</code></A>
! <LI><A HREF="#tocref18">Fully document the interface of front ends to GCC</A>
! </UL>
! <LI><A HREF="#tocref19">Better builtin string functions</A>
! <UL>
! <LI><A HREF="#tocref20">Optimize <code>memset</code></A>
! <LI><A HREF="#tocref21">Optimize <code>strcpy</code></A>
! <LI><A HREF="#tocref22">Optimize <code>strncpy</code></A>
! <LI><A HREF="#tocref23">Optimize <code>strncat</code></A>
! <LI><A HREF="#tocref24">Optimize <code>strcmp</code></A>
! <LI><A HREF="#tocref25">Optimize <code>strncmp</code></A>
! <LI><A HREF="#tocref26">Optimize <code>strcspn</code></A>
! <LI><A HREF="#tocref27">Optimize <code>strspn</code></A>
! <LI><A HREF="#tocref28">Optimize <code>strpbrk</code></A>
! </UL>
! <LI><A HREF="#tocref29">Format (<code>printf</code>, <code>scanf</code> and
! <code>strftime</code>) checking:</A>
! <LI><A HREF="#tocref30">Improve the installation procedure</A>
! <LI><A HREF="#tocref31">The old PROJECTS file</A>
! <UL>
! <LI><A HREF="#tocref32">Putting constants in special sections.</A>
! <LI><A HREF="#tocref33">Optimize a sequence of if statements whose conditions are
! exclusive.</A>
! <LI><A HREF="#tocref34">Un-cse.</A>
! <LI><A HREF="#tocref35">Clean up how cse works.</A>
! <LI><A HREF="#tocref36">Support more general tail-recursion among different functions.</A>
! <LI><A HREF="#tocref37">Keep global variables in registers.</A>
! <LI><A HREF="#tocref38">Live-range splitting.</A>
! <LI><A HREF="#tocref39">Detect dead stores into memory?</A>
! <LI><A HREF="#tocref40">Loop optimization.</A>
! <LI><A HREF="#tocref41">Using constraints on values.</A>
! <LI><A HREF="#tocref42">Change the type of a variable.</A>
! <LI><A HREF="#tocref43">Better handling for very sparse switches.</A>
! <LI><A HREF="#tocref44">Order of subexpressions.</A>
! <LI><A HREF="#tocref45">More code motion.</A>
! <LI><A HREF="#tocref46">Trace scheduling.</A>
! <LI><A HREF="#tocref47">Distributive law.</A>
! <LI><A HREF="#tocref48">Restructuring conditionals</A>
! <LI><A HREF="#tocref49">??? How to call this???</A>
! </UL>
! <LI><A HREF="#tocref50">Simpler porting</A>
! <LI><A HREF="#tocref51">Other languages</A>
! <LI><A HREF="#tocref52">More extensions</A>
! <LI><A HREF="#tocref53">Generalize the machine model</A>
! <LI><A HREF="#tocref54">More warnings</A>
! <LI><A HREF="#tocref55">Better documentation of how GCC works and how to port it</A>
! <LI><A HREF="#tocref56">The old PROBLEMS file</A>
! </UL>
! <!-- table of contents end -->
! 
! 
  <h1 align=center>GCC Projects</h1>
  
+ <h2><A NAME="tocref1">Fix bugs in the GNATS database</h2>
  <p>You can investigate bugs in our <a href="../gnats.html">GNATS
  database</a> and attempt to fix them or see whether they still are
  present in current GCC.
  
+ <h2><A NAME="tocref2">Projects for beginner GCC hackers</h2>
  <p>If you are new to GCC, start with our <a
  href="beginner.html">projects for beginners</a>.
  
+ <h2><A NAME="tocref3">Projects for the C preprocessor</h2>
  <p>There is a separate project list for the <a
  href="cpplib.html">C preprocessor</a>.
  
+ <h2><A NAME="tocref4">Projects for the GCC web pages</h2>
  <p>There is a separate projects list for the <a href="web.html">web
  pages</a>.</p>
  
+ <h2><A NAME="tocref5">Work in progress</h2>
+ Different projects that are in progress.
+ 
+ <h3><A NAME="tocref6">Bounds Checking with Bounded Pointers</h3>
+ <p>There is a separate page for <a
+ href="bp/main.html">Bounds Checking with Bounded Pointers</a>.</p>
+ 
+ <h3><A NAME="tocref7">New register allocator</h3>
+ <p>Daniel Berlin and Michael Matz are working on an implementation of
+ a graph-coloring register allocator. A branch is created in CVS with
+ the tag <code>new-regalloc-branch</code>. It is known to bootstrap
+ under x86-linux and ppc-linux.</p>
+ 
+ <h3><A NAME="tocref8">SSA for trees</h3>
+ <p>Diego Novillo is working on implementing SSA analysis for trees. 
+ A patch was posted at <a
+ href="http://gcc.gnu.org/ml/gcc-patches/2001-03/msg00565.html";></a>.</p>
+ 
+ <h3><A NAME="tocref9">Value range propagation pass</h3>
+ <p>John Wehle (john@feith.com) implemented a <a
+ href="http://gcc.gnu.org/ml/gcc-patches/2000-07/msg00968.html";>value
+ range propagation pass</a> which isn't yet in GCC.</p>
+ 
+ 
+ <h2><A NAME="tocref10">Optimizer inadequacies</h2>
  <p>We also have a page detailing <a href="optimize.html">optimizer
  inadequacies</a>, if you'd prefer to think about it in terms of problems
! instead of features.</p>
  
! <h2><A NAME="tocref11">Changes to support C99 standard</h2>
  
  <p>The new version of the C standard (ISO/IEC 9899:1999) requires a
  number of library changes; these have to be provided by the C library,
***************
*** 36,44 ****
  features.  An <a href="../c99status.html">overview</a> of the C99
  implementation status is available.</p>
  
! <h2>Haifa scheduler</h2> (haifa-sched.c, loop.[ch], unroll.c, genattrtab.c):
! (contact <a href="mailto:law@cygnus.com";>law@cygnus.com</a> before
! starting any serious haifa work)
  
  <ul>
    <li>Fix/add comments throughout the code.  Many of the comments are
--- 135,144 ----
  features.  An <a href="../c99status.html">overview</a> of the C99
  implementation status is available.</p>
  
! <h2><A NAME="tocref12">Improve the Haifa scheduler</h2> (haifa-sched.c, loop.[ch],
! unroll.c, genattrtab.c): (contact <a
! href="mailto:law@cygnus.com";>law@cygnus.com</a> before starting any
! serious haifa work)
  
  <ul>
    <li>Fix/add comments throughout the code.  Many of the comments are
***************
*** 69,75 ****
    they may need to be tuned to generate good schedules with haifa.
  </ul>
  
! <h2>Improvements to global cse and partial redundancy elimination:</h2>
  
  <p>The current implementation of global cse uses partial redundancy
  elimination via lazy code motion (lcm).
--- 169,175 ----
    they may need to be tuned to generate good schedules with haifa.
  </ul>
  
! <h2><A NAME="tocref13">Improvements to global cse and partial redundancy elimination:</h2>
  
  <p>The current implementation of global cse uses partial redundancy
  elimination via lazy code motion (lcm).
***************
*** 85,109 ****
  <p>Contact <a href="mailto:law@cygnus.com";>law@cygnus.com</a> if
  you're interested in working on lazy code motion.</p>
  
! <h2>Miscellaneous ideas:</h2>
  
  <p>The following are some miscellaneous ideas for GCC projects to work
  on.</p>
- 
- <ul>
  
! <li>Convert the Chill front end to use garbage collection instead of
! obstacks, so it can work again with current GCC.</li>
  
! <li>Improve <code>-Wconversion</code> so that it can be used for
  security auditing as well as for its original intended purpose of
  helping with converting old code to ISO C.  See a
  <a href="http://www2.merton.ox.ac.uk/~security/security-audit-200012/0028.html";>message
  to the security-audit list</a> discussing this.  The design for such
  an improved option or collection of options should be discussed with
! the gcc and security-audit lists.</li>
  
! <li>Design and implement builtin functions that assist in implementing
  the ISO C99 <code>&lt;tgmath.h&gt;</code> macros.  These builtins
  could be along the general lines of the macros used in glibc 2.2 (for
  example, the implementation of <code>&lt;tgmath.h&gt;</code> might use
--- 185,211 ----
  <p>Contact <a href="mailto:law@cygnus.com";>law@cygnus.com</a> if
  you're interested in working on lazy code motion.</p>
  
! <h2><A NAME="tocref14">Miscellaneous ideas:</h2>
  
  <p>The following are some miscellaneous ideas for GCC projects to work
  on.</p>
  
! <h3><A NAME="tocref15">Chill should use garbage collection</h3>
! Convert the Chill front end to use garbage collection instead of
! obstacks, so it can work again with current GCC.
  
! <h3><A NAME="tocref16">Improve <code>-Wconversion</code></h3>
! Improve <code>-Wconversion</code> so that it can be used for
  security auditing as well as for its original intended purpose of
  helping with converting old code to ISO C.  See a
  <a href="http://www2.merton.ox.ac.uk/~security/security-audit-200012/0028.html";>message
  to the security-audit list</a> discussing this.  The design for such
  an improved option or collection of options should be discussed with
! the gcc and security-audit lists.
  
! <h3><A NAME="tocref17">Implement various builtin functions for ISO C99's 
! <code>&lt;tgmath.h&gt;</code></h3> 
! Design and implement builtin functions that assist in implementing
  the ISO C99 <code>&lt;tgmath.h&gt;</code> macros.  These builtins
  could be along the general lines of the macros used in glibc 2.2 (for
  example, the implementation of <code>&lt;tgmath.h&gt;</code> might use
***************
*** 116,133 ****
  specifies have real or imaginary result type for imaginary arguments,
  but which have complex result type for complex arguments.  The design
  for these builtins should be discussed with the gcc and libc-alpha
! lists.</li>
  
! <li>Fully document the interface of front ends to GCC (that is, the
  <code>tree</code> interfaces, and the various functions, hooks, etc.,
  that a front end must or may provide).  <code>gcc/c-tree.texi</code>
  includes some of this information; <code>gcc/LANGUAGES</code> contains
  incomplete information about changes that have been made to this
! interface.</li>
  
! </ul>
! 
! <h2>Better builtin string functions</h2>
  
  <p>GNU libc includes some macros to optimize calls to some string
  functions with constant arguments.  These macros tend to cause huge
--- 218,234 ----
  specifies have real or imaginary result type for imaginary arguments,
  but which have complex result type for complex arguments.  The design
  for these builtins should be discussed with the gcc and libc-alpha
! lists.
  
! <h3><A NAME="tocref18">Fully document the interface of front ends to GCC</h3>
! Fully document the interface of front ends to GCC (that is, the
  <code>tree</code> interfaces, and the various functions, hooks, etc.,
  that a front end must or may provide).  <code>gcc/c-tree.texi</code>
  includes some of this information; <code>gcc/LANGUAGES</code> contains
  incomplete information about changes that have been made to this
! interface.
  
! <h2><A NAME="tocref19">Better builtin string functions</h2>
  
  <p>GNU libc includes some macros to optimize calls to some string
  functions with constant arguments.  These macros tend to cause huge
***************
*** 167,175 ****
  <p>Many of these optimizations should not be applied if
  <code>-Os</code> is specified.</p>
  
! <ul>
! 
! <li>GCC optimizes <code>memset</code> only when the value and length
  involved have no side effects, and the value is a constant zero.  On
  architectures allowing unaligned accesses, glibc also optimizes if the
  length is constant and does not exceed 16; the value to which memory
--- 268,275 ----
  <p>Many of these optimizations should not be applied if
  <code>-Os</code> is specified.</p>
  
! <h3><A NAME="tocref20">Optimize <code>memset</code></h3>
! GCC optimizes <code>memset</code> only when the value and length
  involved have no side effects, and the value is a constant zero.  On
  architectures allowing unaligned accesses, glibc also optimizes if the
  length is constant and does not exceed 16; the value to which memory
***************
*** 183,200 ****
  able to optimize if the destination is known to be suitably aligned.
  For example, no alignment is needed for a set of one byte; a set of
  zero bytes should be eliminated in all cases; if two bytes are to be
! set, two byte alignment may suffice; and so on.</li>
  
! <li>GCC converts <code>strcpy</code> from a string constant into a
  <code>memcpy</code> with the known length of that string constant.  In
  turn, <code>emit_block_move</code> may expand that <code>memcpy</code>
  inline.  glibc includes optimizations to load the constant contents of
  the string directly rather than via a memory copy, when no more than 8
  bytes need copying.  <code>emit_block_move</code> could be taught to
  find the contents of the string constant and include the appropriate
! integers directly in the assembler output for the copy.</li>
  
! <li>Similarly, glibc optimizes <code>strncpy</code> from a string
  constant.  Where the maximum length to be copied is not more than the
  length of the string constant including the terminating null
  character, GCC could (but does not) optimize as a
--- 283,302 ----
  able to optimize if the destination is known to be suitably aligned.
  For example, no alignment is needed for a set of one byte; a set of
  zero bytes should be eliminated in all cases; if two bytes are to be
! set, two byte alignment may suffice; and so on.
  
! <h3><A NAME="tocref21">Optimize <code>strcpy</code></h3>
! GCC converts <code>strcpy</code> from a string constant into a
  <code>memcpy</code> with the known length of that string constant.  In
  turn, <code>emit_block_move</code> may expand that <code>memcpy</code>
  inline.  glibc includes optimizations to load the constant contents of
  the string directly rather than via a memory copy, when no more than 8
  bytes need copying.  <code>emit_block_move</code> could be taught to
  find the contents of the string constant and include the appropriate
! integers directly in the assembler output for the copy.
  
! <h3><A NAME="tocref22">Optimize <code>strncpy</code></h3>
! Similarly, glibc optimizes <code>strncpy</code> from a string
  constant.  Where the maximum length to be copied is not more than the
  length of the string constant including the terminating null
  character, GCC could (but does not) optimize as a
***************
*** 203,254 ****
  here glibc can use a micro-optimization not available to GCC, its
  <code>__mempcpy</code> function to copy and return the address after
  the data copied, to pass into <code>memset</code>.  This is only used
! when as inline assembler <code>__mempcpy</code> is available.</li>
  
! <li>glibc optimizes <code>strncat</code> with constant source and
  maximum length.  If the maximum length exceeds the length of the
  source string, it is optimized to <code>strcat</code>; GCC could do
  this (including when the maximum length equals the length of the
  source string).  Otherwise, on architectures where glibc has an
  inline assembler <code>strchr</code> and it is used, glibc converts
  the <code>strncat</code> to a <code>memcpy</code>, but fails to add
! the terminating null character.</li>
  
! <li>glibc has various complicated optimizations for
  <code>strcmp</code>.  The following in GCC would completely cover
  them: comparisons of constant strings should be done at compile time;
  comparisons where one string is constant and of length less than 4
  should be inlined to compare successive bytes to the known constant
  ones (further optimization to compare more than one byte at once is in
  general unsafe as it might access too much memory).  Certain of these
! cases could also be inlined for <code>memcmp</code>.</li>
  
! <li>glibc optimizes <code>strncmp</code>, where one string is constant
  and strictly shorter than the maximum number of characters to be
  compared, by replacing it with <code>strcmp</code> (which may then be
  further optimized).  This may not be safe for GCC except in the cases
  where it handles <code>strcmp</code> internally as above, since
  <code>strcmp</code> may require both strings to be null-terminated
! whereas <code>strncmp</code> doesn't.</li>
  
! <li>glibc optimizes <code>strcspn</code> where the string of excluded
  characters is constant and of length not greater than three.  GCC
  could readily optimize the specific case where the length is zero,
! converting it to <code>strlen</code>.</li>
  
! <li>Similarly, glibc optimizes <code>strspn</code> where not more than
  three characters are involved.  Where there are zero characters
  acceptable in the initial segment, GCC could optimize to the integer
! constant 0.</li>
  
! <li>glibc also has similar optimizations for <code>strpbrk</code>.
  The cases of finding the first occurrence of zero characters (return a
  null pointer) or one character (convert to <code>strchr</code>) could
! readily be optimized by GCC.</li>
  
- </ul>
  
! <h2>Format (<code>printf</code>, <code>scanf</code> and
  <code>strftime</code>) checking:</h2>
  
  <p>Contact <a href="mailto:jsm28@cam.ac.uk";>jsm28@cam.ac.uk</a> before
--- 305,361 ----
  here glibc can use a micro-optimization not available to GCC, its
  <code>__mempcpy</code> function to copy and return the address after
  the data copied, to pass into <code>memset</code>.  This is only used
! when as inline assembler <code>__mempcpy</code> is available.
  
! <h3><A NAME="tocref23">Optimize <code>strncat</code></h3>
! glibc optimizes <code>strncat</code> with constant source and
  maximum length.  If the maximum length exceeds the length of the
  source string, it is optimized to <code>strcat</code>; GCC could do
  this (including when the maximum length equals the length of the
  source string).  Otherwise, on architectures where glibc has an
  inline assembler <code>strchr</code> and it is used, glibc converts
  the <code>strncat</code> to a <code>memcpy</code>, but fails to add
! the terminating null character.
  
! <h3><A NAME="tocref24">Optimize <code>strcmp</code></h3>
! glibc has various complicated optimizations for
  <code>strcmp</code>.  The following in GCC would completely cover
  them: comparisons of constant strings should be done at compile time;
  comparisons where one string is constant and of length less than 4
  should be inlined to compare successive bytes to the known constant
  ones (further optimization to compare more than one byte at once is in
  general unsafe as it might access too much memory).  Certain of these
! cases could also be inlined for <code>memcmp</code>.
  
! <h3><A NAME="tocref25">Optimize <code>strncmp</code></h3>
! glibc optimizes <code>strncmp</code>, where one string is constant
  and strictly shorter than the maximum number of characters to be
  compared, by replacing it with <code>strcmp</code> (which may then be
  further optimized).  This may not be safe for GCC except in the cases
  where it handles <code>strcmp</code> internally as above, since
  <code>strcmp</code> may require both strings to be null-terminated
! whereas <code>strncmp</code> doesn't.
  
! <h3><A NAME="tocref26">Optimize <code>strcspn</code></h3>
! glibc optimizes <code>strcspn</code> where the string of excluded
  characters is constant and of length not greater than three.  GCC
  could readily optimize the specific case where the length is zero,
! converting it to <code>strlen</code>.
  
! <h3><A NAME="tocref27">Optimize <code>strspn</code></h3>
! Similarly, glibc optimizes <code>strspn</code> where not more than
  three characters are involved.  Where there are zero characters
  acceptable in the initial segment, GCC could optimize to the integer
! constant 0.
  
! <h3><A NAME="tocref28">Optimize <code>strpbrk</code></h3>
! glibc also has similar optimizations for <code>strpbrk</code>.
  The cases of finding the first occurrence of zero characters (return a
  null pointer) or one character (convert to <code>strchr</code>) could
! readily be optimized by GCC.
  
  
! <h2><A NAME="tocref29">Format (<code>printf</code>, <code>scanf</code> and
  <code>strftime</code>) checking:</h2>
  
  <p>Contact <a href="mailto:jsm28@cam.ac.uk";>jsm28@cam.ac.uk</a> before
***************
*** 358,364 ****
  
  </ul>
  
! <h2>Installation:</h2>
  
  <p>Contact <a href="mailto:zackw@stanford.edu";>zackw@stanford.edu</a>
  before working on improvements to installation.</p>
--- 465,471 ----
  
  </ul>
  
! <h2><A NAME="tocref30">Improve the installation procedure</h2>
  
  <p>Contact <a href="mailto:zackw@stanford.edu";>zackw@stanford.edu</a>
  before working on improvements to installation.</p>
***************
*** 416,430 ****
  
  <hr>
  
! <h1>The old PROJECTS file</h1>
  
  <p>Stuff I know has been done has been deleted.
  Stuff in progress has a contact name associated with it.</p>
  
  <p>Better optimization.
  
! <ol>
! <li>Putting constants in special sections.
  
  <p>If a function has been placed in a special
  section via attributes, we may want to put its static data and string
--- 523,537 ----
  
  <hr>
  
! <h2><A NAME="tocref31">The old PROJECTS file</h2>
  
  <p>Stuff I know has been done has been deleted.
  Stuff in progress has a contact name associated with it.</p>
  
  <p>Better optimization.
+ 
  
! <h3><A NAME="tocref32">Putting constants in special sections.</h3>
  
  <p>If a function has been placed in a special
  section via attributes, we may want to put its static data and string
***************
*** 432,439 ****
  specify a section for string constants would be useful for the Linux
  kernel.)
  
! <li>Optimize a sequence of if statements whose conditions are
! exclusive.
  
  <p>It is possible to optimize
  
--- 539,546 ----
  specify a section for string constants would be useful for the Linux
  kernel.)
  
! <h3><A NAME="tocref33">Optimize a sequence of if statements whose conditions are
! exclusive.</h3>
  
  <p>It is possible to optimize
  
***************
*** 454,460 ****
  nearly always write the else's themselves, leaving few opportunities
  to improve anything.
  
! <li>Un-cse.
  
  <p>Perhaps we should have an un-cse step right after cse, which tries to
  replace a reg with its value if the value can be substituted for the
--- 561,567 ----
  nearly always write the else's themselves, leaving few opportunities
  to improve anything.
  
! <h3><A NAME="tocref34">Un-cse.</h3>
  
  <p>Perhaps we should have an un-cse step right after cse, which tries to
  replace a reg with its value if the value can be substituted for the
***************
*** 462,468 ****
  reg is used only a few times.  Use rtx_cost to determine if the
  change is really an improvement.
  
! <li>Clean up how cse works.
  
  <p>The scheme is that each value has just one hash entry.  The
  first_same_value and next_same_value chains are no longer needed.
--- 569,575 ----
  reg is used only a few times.  Use rtx_cost to determine if the
  change is really an improvement.
  
! <h3><A NAME="tocref35">Clean up how cse works.</h3>
  
  <p>The scheme is that each value has just one hash entry.  The
  first_same_value and next_same_value chains are no longer needed.
***************
*** 516,522 ****
  to see if there is a reg or mem that is equiv to a particular value.
  If the value is constant, it is always explicitly constant.
  
! <li>Support more general tail-recursion among different functions.
  
  <p>This might be possible under certain circumstances, such as when
  the argument lists of the functions have the same lengths.  Perhaps it
--- 623,629 ----
  to see if there is a reg or mem that is equiv to a particular value.
  If the value is constant, it is always explicitly constant.
  
! <h3><A NAME="tocref36">Support more general tail-recursion among different functions.</h3>
  
  <p>This might be possible under certain circumstances, such as when
  the argument lists of the functions have the same lengths.  Perhaps it
***************
*** 533,539 ****
  one has a linker that works with the feature.  This is said to make a
  15% speedup on the 68000.
  
! <li>Keep global variables in registers.
  
  <p>Here is a scheme for doing this.  A global variable, or a local variable
  whose address is taken, can be kept in a register for an entire function
--- 640,646 ----
  one has a linker that works with the feature.  This is said to make a
  15% speedup on the 68000.
  
! <h3><A NAME="tocref37">Keep global variables in registers.</h3>
  
  <p>Here is a scheme for doing this.  A global variable, or a local variable
  whose address is taken, can be kept in a register for an entire function
***************
*** 562,568 ****
  level around the appropriate loop and define the variable name as a
  register variable with that scope.
  
! <li>Live-range splitting.
  
  <p>Currently a variable is allocated a hard register either for the
  full extent of its use or not at all.  Sometimes it would be good to
--- 669,675 ----
  level around the appropriate loop and define the variable name as a
  register variable with that scope.
  
! <h3><A NAME="tocref38">Live-range splitting.</h3>
  
  <p>Currently a variable is allocated a hard register either for the
  full extent of its use or not at all.  Sometimes it would be good to
***************
*** 575,581 ****
  Contact <a href="mailto:meissner@cygnus.com";>meissner@cygnus.com</a>
  before starting any work on live range splitting.
  
! <li>Detect dead stores into memory?
  
  <p>A store into memory is dead if it is followed by another store into
  the same location; and, in between, there is no reference to anything
--- 682,688 ----
  Contact <a href="mailto:meissner@cygnus.com";>meissner@cygnus.com</a>
  before starting any work on live range splitting.
  
! <h3><A NAME="tocref39">Detect dead stores into memory?</h3>
  
  <p>A store into memory is dead if it is followed by another store into
  the same location; and, in between, there is no reference to anything
***************
*** 587,593 ****
  href="mailto:law@cygnus.com";>law@cygnus.com</a> before working on dead
  store elimination optimizations.
  
! <li>Loop optimization.
  
  <p>Strength reduction and iteration variable elimination could be
  smarter.  They should know how to decide which iteration variables are
--- 694,700 ----
  href="mailto:law@cygnus.com";>law@cygnus.com</a> before working on dead
  store elimination optimizations.
  
! <h3><A NAME="tocref40">Loop optimization.</h3>
  
  <p>Strength reduction and iteration variable elimination could be
  smarter.  They should know how to decide which iteration variables are
***************
*** 604,610 ****
  in after the increment, decrement the loop count and jump to the
  increment.  This allows aob insns to be used.
  
! <li>Using constraints on values.
  
  <p>Many operations could be simplified based on knowledge of the
  minimum and maximum possible values of a register at any particular
--- 711,717 ----
  in after the increment, decrement the loop count and jump to the
  increment.  This allows aob insns to be used.
  
! <h3><A NAME="tocref41">Using constraints on values.</h3>
  
  <p>Many operations could be simplified based on knowledge of the
  minimum and maximum possible values of a register at any particular
***************
*** 625,631 ****
  href="http://gcc.gnu.org/ml/gcc-patches/2000-07/msg00968.html";>value
  range propagation pass</a> which isn't yet in GCC.</p>
  
! <li>Change the type of a variable.
  
  <p>Sometimes a variable is declared as <code>int</code>, it is
  assigned only once from a value of type <code>char</code>, and then it
--- 732,738 ----
  href="http://gcc.gnu.org/ml/gcc-patches/2000-07/msg00968.html";>value
  range propagation pass</a> which isn't yet in GCC.</p>
  
! <h3><A NAME="tocref42">Change the type of a variable.</h3>
  
  <p>Sometimes a variable is declared as <code>int</code>, it is
  assigned only once from a value of type <code>char</code>, and then it
***************
*** 634,664 ****
  If the compiler could detect this case, it could change the
  declaration of the variable and change all the places that use it.
  
! <li>Better handling for very sparse switches.
  
  <p>There may be cases where it would be better to compile a switch
  statement to use a fixed hash table rather than the current
  combination of jump tables and binary search.
  
! <li>Order of subexpressions.
  
  <p>It might be possible to make better code by paying attention to the
  order in which to generate code for subexpressions of an expression.
  
! <li>More code motion.
  
  <p>Consider hoisting common code up past conditional branches or tablejumps.
  
  <p>Contact <a href="mailto:law@cygnus.com";>law@cygnus.com</a> before
  working on code hoisting.
  
! <li>Trace scheduling.
  
  <p>This technique is said to be able to figure out which way a jump
  will usually go, and rearrange the code to make that path the
  faster one.
  
! <li>Distributive law.
  
  <p>The C expression <code>*(X + 4 * (Y + C))</code> compiles better on
  certain machines if rewritten as <code>*(X + 4*C + 4*Y)</code> because
--- 741,771 ----
  If the compiler could detect this case, it could change the
  declaration of the variable and change all the places that use it.
  
! <h3><A NAME="tocref43">Better handling for very sparse switches.</h3>
  
  <p>There may be cases where it would be better to compile a switch
  statement to use a fixed hash table rather than the current
  combination of jump tables and binary search.
  
! <h3><A NAME="tocref44">Order of subexpressions.</h3>
  
  <p>It might be possible to make better code by paying attention to the
  order in which to generate code for subexpressions of an expression.
  
! <h3><A NAME="tocref45">More code motion.</h3>
  
  <p>Consider hoisting common code up past conditional branches or tablejumps.
  
  <p>Contact <a href="mailto:law@cygnus.com";>law@cygnus.com</a> before
  working on code hoisting.
  
! <h3><A NAME="tocref46">Trace scheduling.</h3>
  
  <p>This technique is said to be able to figure out which way a jump
  will usually go, and rearrange the code to make that path the
  faster one.
  
! <h3><A NAME="tocref47">Distributive law.</h3>
  
  <p>The C expression <code>*(X + 4 * (Y + C))</code> compiles better on
  certain machines if rewritten as <code>*(X + 4*C + 4*Y)</code> because
***************
*** 667,678 ****
  
  <p>Some work has been done on this, in combine.c.
  
! <li>Can optimize by changing <code>if (x) y; else z;</code> into
  <code>z; if (x) y;</code> if z and x do not interfere and z has no
  effects not undone by y.  This is desirable if z is faster than
  jumping.
  
! <li>For a two-insn loop on the 68020, such as
  <pre>
  foo:	movb	a2@+,a3@+
  	jne	foo
--- 774,787 ----
  
  <p>Some work has been done on this, in combine.c.
  
! <h3><A NAME="tocref48">Restructuring conditionals</h3>
! Can optimize by changing <code>if (x) y; else z;</code> into
  <code>z; if (x) y;</code> if z and x do not interfere and z has no
  effects not undone by y.  This is desirable if z is faster than
  jumping.
  
! <h3><A NAME="tocref49">??? How to call this???</h3>
! For a two-insn loop on the 68020, such as
  <pre>
  foo:	movb	a2@+,a3@+
  	jne	foo
***************
*** 681,689 ****
  <code>d0</code> can be a junk register.  The challenge is to fit this
  into a portable framework: when can you detect this situation and
  still be able to allocate a junk register?
! </ol>
  
! <h2>Simpler porting</h2>
  
  <p>Right now, describing the target machine's instructions is done
  cleanly, but describing its addressing mode is done with several
--- 790,798 ----
  <code>d0</code> can be a junk register.  The challenge is to fit this
  into a portable framework: when can you detect this situation and
  still be able to allocate a junk register?
! 
  
! <h2><A NAME="tocref50">Simpler porting</h2>
  
  <p>Right now, describing the target machine's instructions is done
  cleanly, but describing its addressing mode is done with several
***************
*** 706,712 ****
        in the RTL expression.
  </ul>
  
! <h2>Other languages</h2>
  
  <p>We currently have front ends for C, C++, Objective C, CHILL,
  Fortran, and Java.  Pascal and Ada front ends exist but have not yet
--- 815,821 ----
        in the RTL expression.
  </ul>
  
! <h2><A NAME="tocref51">Other languages</h2>
  
  <p>We currently have front ends for C, C++, Objective C, CHILL,
  Fortran, and Java.  Pascal and Ada front ends exist but have not yet
***************
*** 718,724 ****
  <p>Pascal, Modula-2 and Ada require the implementation of functions
  within functions.  Some of the mechanisms for this already exist.
  
! <h2>More extensions</h2>
  
  <ul>
  <li>Generated unique labels.  Have some way of generating distinct
--- 827,833 ----
  <p>Pascal, Modula-2 and Ada require the implementation of functions
  within functions.  Some of the mechanisms for this already exist.
  
! <h2><A NAME="tocref52">More extensions</h2>
  
  <ul>
  <li>Generated unique labels.  Have some way of generating distinct
***************
*** 745,751 ****
  several components of the structure into the variables a, b, and c.
  </ul>
  
! <h2>Generalize the machine model</h2>
  
  <p>Some new compiler features may be needed to do a good job on
  machines where static data needs to be addressed using base registers.
--- 854,860 ----
  several components of the structure into the variables a, b, and c.
  </ul>
  
! <h2><A NAME="tocref53">Generalize the machine model</h2>
  
  <p>Some new compiler features may be needed to do a good job on
  machines where static data needs to be addressed using base registers.
***************
*** 757,763 ****
  <p>The scheduler does not do very well on recent RISC machines.  Haifa
  helps but not enough.
  
! <h2>More warnings</h2>
  
  <p>Warn about statements that are undefined because the order of
  evaluation of increment operators makes a big difference.  Here is an
--- 866,872 ----
  <p>The scheduler does not do very well on recent RISC machines.  Haifa
  helps but not enough.
  
! <h2><A NAME="tocref54">More warnings</h2>
  
  <p>Warn about statements that are undefined because the order of
  evaluation of increment operators makes a big difference.  Here is an
***************
*** 769,775 ****
  <p><code>-Wsequence-point</code> does some of this, but not that
  particular case.</p>
  
! <h2>Better documentation of how GCC works and how to port it</h2>
  
  <p>Here is an outline proposed by Allan Adler.
  
--- 878,884 ----
  <p><code>-Wsequence-point</code> does some of this, but not that
  particular case.</p>
  
! <h2><A NAME="tocref55">Better documentation of how GCC works and how to port it</h2>
  
  <p>Here is an outline proposed by Allan Adler.
  
***************
*** 866,872 ****
  
  <hr>
  
! <h1>The old PROBLEMS file</h1>
  
  <p>The following used to be in a file <code>PROBLEMS</code> in the GCC
  distribution.  Probably much of it is no longer relevant as of GCC 3.0
--- 975,981 ----
  
  <hr>
  
! <h2><A NAME="tocref56">The old PROBLEMS file</h2>
  
  <p>The following used to be in a file <code>PROBLEMS</code> in the GCC
  distribution.  Probably much of it is no longer relevant as of GCC 3.0


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]