projects.html patch: merge PROBLEMS

["Joseph S. Myers" <jsm28 at cam dot ac dot uk>]

This patch merges PROBLEMS into projects.html.  (PROBLEMS has not changed
since the start of EGCS - in fact, a little checking shows the current
PROBLEMS file is identical to that in GCC 2.0.)

OK to commit this patch and remove PROBLEMS?

(If anyone notices items from PROBLEMS in this patch that they know are
out of date, I suggest sending them as separate patches to be applied
after this patch rather than as comments on the content of this patch
which simply moves the contents of the current PROBLEMS file.)

--- projects.html.orig	Wed Oct 11 21:56:06 2000
+++ projects.html	Sat Oct 14 16:56:34 2000
@@ -600,5 +600,147 @@
 <li>  References to the literature for the algorithms used in GCC
 </ol>
 
+<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, but some
+might be.  Someone should go through it, identifying what is and isn't
+relevant, adding anything applicable to current GCC (and describing a
+bug) to GNATS and sending patches to gcc-patches to remove from the
+list entries that no longer apply or have been entered in GNATS.</p>
+
+<ol>
+
+<li value=3>When <code>find_reloads</code> is used to count number of
+spills needed it does not take into account the fact that a reload may
+turn out to be a dummy.
+
+<p>I'm not sure this really happens any more.  Doesn't it find all the
+dummies on both passes?</p></li>
+
+<li value=10>
+<pre>
+        movl a3@,a0
+        movl a3@(16),a1
+        clrb a0@(a1:l)
+</pre>
+<p>is generated and may be worse than</p>
+<pre>
+        movl a3@,a0
+        addl a3@(16),a0
+        clrb a0@
+</pre>
+<p>If ordering of operands is improved, many more such cases will be
+generated from typical array accesses.</p></li>
+
+<li value=38>Hack <code>expand_mult</code> so that if there is no
+same-modes multiply it will use a widening multiply and then truncate
+rather than calling the library.</li>
+
+<li value=39>Hack expanding of division to notice cases for long -&gt;
+short division.</li>
+
+<li value=40>Represent divide insns as (DIV:SI ...) followed by a
+separate lowpart extract.  Represent remainder insns as DIV:SI
+followed by a separate highpart extract.  Then cse can work on the
+DIV:SI part.  Problem is, this may not be desirable on machines where
+computing the quotient alone does not necessarily give a
+remainder--such as the 68020 for long operands.</li>
+
+<li value=52>Reloading can look at how <code>reload_contents</code>
+got set up.  If it was copied from a register, just reload from that
+register.  Otherwise, perhaps can change the previous insn to move the
+data via the reload reg, thus avoiding one memory ref.</li>
+
+<li value=63>Potential problem in <code>cc_status.value2</code>, if it
+ever activates itself after a two-address subtraction (which currently
+cannot happen).  It is supposed to compare the current value of the
+destination but eliminating it would use the results of the
+subtraction, equivalent to comparing the previous value of the
+destination.</li>
+
+<li value=65>Should loops that neither start nor end with a break be
+rearranged to end with the last break?</li>
+
+<li value=69>Define the floating point converting arithmetic
+instructions for the 68881.</li>
+
+<li value=74>Combine loop opt with cse opt in one pass.  Do cse on
+each loop, then loop opt on that loop, and go from innermost loops
+outward.  Make loop invariants available for cse at end of loop.</li>
+
+<li value=85>pea can force a value to be reloaded into an areg which
+can make it worse than separate adding and pushing.  This can only
+happen for adding something within addql range and it only loses if
+the qty becomes dead at that point so it can be added to with no
+copying.</li>
+
+<li value=93>If a pseudo doesn't get a hard reg everywhere, can it get
+one during a loop?</li>
+
+<li value=96>Can do SImode bitfield insns without reloading, but must
+alter the operands in special ways.</li>
+
+<li value=99>final could check loop-entry branches to see if they
+screw up deletion of a test instruction.  If they do, can put another
+test instruction before the branch and make it conditional and
+redirect it.</li>
+
+<li value=106>Aliasing may be impossible if data types of refs differ
+and data type of containing objects also differ.  (But check this wrt
+unions.)</li>
+
+<li value=108>Can speed up flow analysis by making a table saying
+which register is set and which registers are used by each instruction
+that only sets one register and only uses two.  This way avoid the
+tree walk for such instructions (most instructions).</li>
+
+<li value=109>It is desirable to avoid converting INDEX to SImode if a
+narrower mode suffices, as HImode does on the 68000.  How can this be
+done?</li>
+
+<li value=110>Possible special combination pattern: If the two
+operands to a comparison die there and both come from insns that are
+identical except for replacing one operand with the other, throw away
+those insns.  Ok if insns being discarded are known 1 to 1.  An andl
+#1 after a seq is 1 to 1, but how should compiler know that?</li>
+
+<li value=112>Can convert float to unsigned int by subtracting a
+constant, converting to signed int, and changing the sign bit.</li>
+
+<li value=117>Any number of slow zero-extensions in one loop, that
+have their clr insns moved out of the loop, can share one register if
+their original life spans are disjoint.  But it may be hard to be sure
+of this since the life span data that regscan produces may be hard to
+interpret validly or may be incorrect after cse.</li>
+
+<li value=118>In cse, when a bfext insn refers to a register, if the
+field corresponds to a halfword or a byte and the register is
+equivalent to a memory location, it would be possible to detect this
+and replace it with a simple memory reference.</li>
+
+<li value=121>Insns that store two values cannot be moved out of
+loops.  The code in <code>scan_loop</code> doesn't even try to deal
+with them.</li>
+
+<li value=122>When <code>insn-output.c</code> turns a bit-test into a
+sign-test, it should see whether the cc is already set up with that
+sign.</li>
+
+<li value=123>When a conditional expression is used as a function arg,
+it would be faster (and in some cases shorter) to push each
+alternative rather than compute in a register and push that.  This
+would require being able to specify "push this" as a target for
+<code>expand_expr</code>.</li>
+
+<li value=124>On the 386, bad code results from <code>foo (bar
+())</code> when <code>bar</code> returns a double, because the pseudo
+used fails to get preferenced into an fp reg because of the
+distinction between regs 8 and 9.</li>
+
+</ol>
+
 </body>
 </html>

-- 
Joseph S. Myers
jsm28@cam.ac.uk