[wwwdocs] Re: More OLD PROBLEMS problems

Steven Bosscher stevenb@suse.de
Sun Dec 12 11:49:00 GMT 2004


On Sunday 12 December 2004 02:45, Peter Barada wrote:
> >My original plan was to move all the remaining m68k "problems", including
> >the ones you commented on, to a page with "projects for the m68k".
> >Is that OK with you?
>
> Ah, I read "remove all entries" as being that they would get dropped
> on the floor.  Moving them to their own m68k/ColdFire page sounds
> fine.

Dropping them on the floor would not even be unreasonable, you know,
as clearly nobody cares enough about the issues mentioned there to
do anything about it.  At least, nobody in the last 15 years or so,
because that is how long these items have been around without anyone
fixing the problems :-)

Having bugs filed for the remaining issues would be better IMO than
creating an m68k projects page.  Since the "old problems" do not
have test cases, and I don't understand them all, I decided to move
them to a separate web page instead of to /dev/null.  But if you do
understand the problems and you can file bugs (with test cases!) for
each of them, I think that would be much better.

In the mean time, the attached patch removes the items that Ian
commented on.  OK?

There are 9 remaining "old problems", 4 of which are m68k specific.
For the rest, let's see if we can get enhancement requests filed.

Gr.
Steven

Index: index.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/projects/index.html,v
retrieving revision 1.53
diff -u -3 -p -r1.53 index.html
--- index.html	3 Dec 2004 19:57:11 -0000	1.53
+++ index.html	12 Dec 2004 11:44:49 -0000
@@ -551,20 +551,6 @@ gcc-patches to remove such analysed entr
   <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 ->
-  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
-  DI V: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="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
@@ -572,18 +558,12 @@ gcc-patches to remove such analysed entr
   subtraction, equivalent to comparing the previous value of the
   destination.</li>
 
-  <li value="69">Define the floating point converting arithmetic
-  instructions for the 68881.</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="96">Can do SImode bitfield insns without reloading, but must
-  alter the operands in special ways.</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
@@ -599,9 +579,6 @@ gcc-patches to remove such analysed entr
   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



More information about the Gcc mailing list