public inbox for cgen@sourceware.org
 help / color / mirror / Atom feed
From: Doug Evans <dje@transmeta.com>
To: Dave Brolley <brolley@redhat.com>
Cc: cgen@sources.redhat.com
Subject: [patch][rfa] Add ltu,leu,gtu,geu support for unsigned modes
Date: Thu, 08 May 2003 17:17:00 -0000	[thread overview]
Message-ID: <16058.37129.53035.140393@casey.transmeta.com> (raw)
In-Reply-To: <3EB80E66.70402@redhat.com>

Dave Brolley writes:
 > Hi,
 > 
 > The attached patch adds support for the unsigned modes (UQI, UHI, USI, 
 > UDI, UINT) for the cgen rtl ops ltu, leu, gtu and geu. These calls can 
 > be generated by code like
 > 
 > (if (ltu (zext UDI op1) (zext UDI op2 ))(set op3 op1 ))
 > 
 > ok to commit?

Well ....

The first indication that you're barking up the wrong tree is that
cgen-ops.h generally doesn't have Umode support (e.g. ADDUSI).
There's a reason.  It's excessive and unnecessary and I don't want
to unnecessarily propagate them.  GCC doesn't have Umodes.
I added Umodes mostly as an escape hatch, but a controlled one.
If this patch goes in and the general direction it takes cgen-ops.h in
is allowed to proceed, I think that's a bad thing.

Do you get the desired result if you replace the above with

  (if (ltu (zext DI op1) (zext DI op2 ))(set op3 op1 ))

?

Note this: from doc/rtl.texi:

@item UQI,UHI,USI,UDI
Unsigned versions of QI,HI,SI,DI.

These modes do not appear in semantic RTL.  Instead, the RTL function
specifies the signedness of its operands where necessary.

??? I'm not entirely sure these unsigned modes are needed.
They are useful in removing any ambiguity in how to sign extend constants
which has been a source of problems in GCC.

??? Some existing ports use these modes.

  parent reply	other threads:[~2003-05-08 17:17 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-06 19:35 Dave Brolley
2003-05-06 21:57 ` Dave Brolley
2003-05-06 22:42 ` Ben Elliston
2003-05-08 17:17 ` Doug Evans [this message]
2003-05-08 18:18   ` Dave Brolley
2003-05-09 16:17     ` Doug Evans
2003-06-13 20:02     ` Dave Brolley

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=16058.37129.53035.140393@casey.transmeta.com \
    --to=dje@transmeta.com \
    --cc=brolley@redhat.com \
    --cc=cgen@sources.redhat.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).