public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Steven Bosscher <stevenb@suse.de>
To: gcc@gcc.gnu.org
Subject: More OLD PROBLEMS problems
Date: Fri, 10 Dec 2004 14:29:00 -0000	[thread overview]
Message-ID: <1300156.1102688988622.SLOX.WebMail.wwwrun@extimap.suse.de> (raw)

Hi,

Can anyone give more details about the following listed OLD PROBLEMS
on http://gcc.gnu.org/projects/intex.html.  I'd like to get rid of
those that lack a clear explanation of the actual problem.  If nobody
knows what the problem is/was, I'll post a patch to remove the items
as I really don't see any point in listing problems that nobody knows
anything about.

Here we go:

  <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>

I couldn't find where expand_mult does do this, but it appears that
this problem was fixed at one point.  For example:

char a; short b;
short foo (void) { return a * b; }

--> .rtl (gcc 3.3.5):
                                                                                                  
(insn 10 9 11 (nil) (set (reg:QI 61)
        (mem/f:QI (symbol_ref:SI ("a")) [0 a+0 S1 A8])) -1 (nil)
    (nil))
                                                                                        
(insn 11 10 12 (nil) (set (reg:HI 60)
        (sign_extend:HI (reg:QI 61))) -1 (nil)
    (nil))
                                                                                        
(insn 12 11 13 (nil) (set (reg:HI 62)
        (mem/f:HI (symbol_ref:SI ("b")) [2 b+0 S2 A16])) -1 (nil)
    (nil))
                                                                                        
(insn 13 12 14 (nil) (parallel [
            (set (reg:HI 63)
                (mult:HI (reg:HI 60)
                    (reg:HI 62)))
            (clobber (reg:CC 17 flags))
        ]) -1 (nil)
    (nil))

--> asm:

foo:
        movsbw  a,%ax
        imulw   b, %ax
        cwtl
        ret

Which looks pretty OK to me.  Is there any target for which this
would not work?  Any objections to me removing this "problem"?



  <li value="39">Hack expanding of division to notice cases for long -&gt;
  short division.</li>

Ehm right, I don't understand this problem.  Anyone?



  <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>

I don't think we want to do this.



  <li value="69">Define the floating point converting arithmetic
  instructions for the 68881.</li>

Which instructions are this?  Are they implemented?  (Schwab? ;-)



  <li value="96">Can do SImode bitfield insns without reloading, but must
  alter the operands in special ways.</li>

Another one that could use some explaining.



  <li value="112">Can convert float to unsigned int by subtracting a
  constant, converting to signed int, and changing the sign bit.</li>

And again.



  <li value="122">When <code>insn-output.c</code> turns a bit-test into a
  sign-test, it should see whether the condition code is already set up
  with that sign.</li>

Isn't this a job for final?


Help me out here!  :-)

Gr.
Steven


             reply	other threads:[~2004-12-10 14:29 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-12-10 14:29 Steven Bosscher [this message]
2004-12-10 18:38 ` Ian Lance Taylor
2004-12-10 19:31   ` Peter Barada
2004-12-10 19:38     ` Ian Lance Taylor
2004-12-11 17:45   ` Gerald Pfeifer
2004-12-12  0:13     ` Peter Barada
2004-12-12  0:38       ` Steven Bosscher
2004-12-12  1:20         ` Ian Lance Taylor
2004-12-12  1:45         ` Peter Barada
2004-12-12 11:49           ` [wwwdocs] " Steven Bosscher
2004-12-12 14:19             ` Gerald Pfeifer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1300156.1102688988622.SLOX.WebMail.wwwrun@extimap.suse.de \
    --to=stevenb@suse.de \
    --cc=gcc@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).