public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Adam Nemet <anemet@caviumnetworks.com>
To: Ian Lance Taylor <iant@google.com>
Cc: gcc@gcc.gnu.org,     law@redhat.com
Subject: Re: Rationale for an old TRUNCATE patch
Date: Tue, 16 Jun 2009 22:45:00 -0000	[thread overview]
Message-ID: <19000.8283.533096.76324@ropi.home> (raw)
In-Reply-To: <m3iqiw4571.fsf@google.com>

Ian Lance Taylor writes:
> I agree that this patch looks wrong in todays compiler.  There should be
> no need to call TRULY_NOOP_TRUNCATION if you are in a TRUNCATE anyhow.

Thanks.

Do you think we can assume this for TRUNCATEs in general or only for MIPS-like
TRUNCATEs?

I can't think of why it would be useful to represent a mode so that bits
outside the mode mask don't either depent on bits inside the mask or are
don't-care bits.  IOW, can we assume that for any TRUNCATE from wider mode W
to narrower mode N the following holds:

  (truncate:N expr:W) == (truncate:N (and:W expr:W GET_MODE_MASK(Nmode)))

?  Where == is not necessarily identical bit representation of the object
holding the value (e.g. QI HI values in MIPS) but that they are
indistinguishable in the operations that are defined on them.

Adam

  reply	other threads:[~2009-06-16 22:45 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-16  7:12 Adam Nemet
2009-06-16 14:35 ` Ian Lance Taylor
2009-06-16 22:45   ` Adam Nemet [this message]
2009-06-17  0:28     ` Ian Lance Taylor
2009-06-17  6:42       ` Adam Nemet
2009-06-17 14:24         ` Ian Lance Taylor
2009-06-17 15:26           ` Adam Nemet
2009-06-17 15:54             ` Ian Lance Taylor
2009-06-17  2:12   ` Jeff Law
2009-06-17  6:17     ` Adam Nemet
2009-06-17 14:52       ` Jeff Law
2009-06-17  2:10 ` Jeff Law

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=19000.8283.533096.76324@ropi.home \
    --to=anemet@caviumnetworks.com \
    --cc=gcc@gcc.gnu.org \
    --cc=iant@google.com \
    --cc=law@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).