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 ->
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
next 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).