public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Steve Ellcey <sje@cup.hp.com>
To: rsandifo@redhat.com, zack@codesourcery.com
Cc: gcc@gcc.gnu.org
Subject: Re: RFC: Using mode and code macros in *.md files
Date: Tue, 31 Aug 2004 21:04:00 -0000	[thread overview]
Message-ID: <200408312056.NAA26227@hpsje.cup.hp.com> (raw)
In-Reply-To: <87r7pnw45v.fsf@redhat.com>

> That should certainly do the trick.  (Do you really want to
> include XF though?  I'm not sure whether it's OK to have
> (float_extend:XF (reg:XF ...)).)

You are right, I probably don't want to include XF, the unfortunate
aspect of this is that I probably need 6 versions of addxf then, one
version where one operand has a float_extend, one where both operands
are extended, and on where neither are extended.  I would also want each
of those to have a version where the result is truncated after the add
because on IA64 we can do that truncation as part of the single add
instruction.

One thought I had was this:  If there were an IF mode (infinite
precision), and a single basic floating point add for that mode

(set (match_operand:IF ...)
     (plus:IF (match_operand:IF ...)
              (match_operand:IF ...)))

and then there would be no basic add instruction for any other floating
point mode (SF, DF, or XF) then GCC will extend any of those to IFmode
to do the add.  I tested that and GCC did the float_extends.

Then all SF, DF, and XF addition could all be handled with one
macro'ized instruction:

;; AF == Any floating point type that can fit in a register.
(define_mode_macro AF0 [(SF "") (DF "") (XF "")])
(define_mode_macro AF1 [(SF "") (DF "") (XF "")])
(define_mode_macro AF2 [(SF "") (DF "") (XF "")])

(set (match_operand:AF0 0 "fr_register_operand" "=f")
     (float_truncate:AF0
       (plus:IF (float_extend:IF
                  (match_operand:AF1 1 "fr_register_operand" "%f"))
                (float_extend:IF
                  (match_operand:AF2 2 "fr_reg_or_fp01_operand" "fG")))))


Steve Ellcey
sje@cup.hp.com

  parent reply	other threads:[~2004-08-31 20:56 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-07 18:38 Richard Sandiford
2004-08-08  4:30 ` James E Wilson
2004-08-08  8:43   ` Richard Sandiford
2004-08-09 18:29     ` James E Wilson
2004-08-09  9:02   ` Michael Matz
2004-08-09 18:09     ` James E Wilson
2004-08-10  8:57 ` Segher Boessenkool
2004-08-23 10:32 ` Zack Weinberg
2004-08-26 21:08   ` Richard Sandiford
2004-08-31 18:19     ` Steve Ellcey
2004-08-31 18:37       ` Richard Sandiford
2004-08-31 19:27         ` Joern Rennecke
2004-08-31 21:04         ` Steve Ellcey [this message]
2004-09-01 12:20           ` Joern Rennecke
2004-09-01 18:33             ` Steve Ellcey
2004-09-01 19:00               ` James E Wilson
2004-09-02 10:37               ` Joern Rennecke

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=200408312056.NAA26227@hpsje.cup.hp.com \
    --to=sje@cup.hp.com \
    --cc=gcc@gcc.gnu.org \
    --cc=rsandifo@redhat.com \
    --cc=zack@codesourcery.com \
    /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).