public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: law@redhat.com
To: kenner@vlsi1.ultra.nyu.edu (Richard Kenner)
Cc: gcc@gcc.gnu.org
Subject: Re: paradoxical subreg problem
Date: Mon, 28 Jan 2002 12:47:00 -0000	[thread overview]
Message-ID: <16847.1012247749@porcupine.cygnus.com> (raw)
In-Reply-To: Your message of Mon, 28 Jan 2002 14:35:28 EST. <10201281935.AA25716@vlsi1.ultra.nyu.edu>

In message <10201281935.AA25716@vlsi1.ultra.nyu.edu>, Richard Kenner writes:
 >     Don't assume you can break it into two expressions.  Consider the
 >     expression as it stands (and as combine creates it).
 > 
 > Sure, but I'm trying to define what it means by comparison with
 > two expressions.
 > 
 >     So with your assertions in mind are these two expresions equivalent?
 > 
 >     (and:SI (subreg:SI (mem:QI) 0) (const_int 255))
 > 
 >     (subreg:SI (mem:QI X) 0)
OK.  So let's go back to this expression:

(eq (subreg:SI (mem/s:QI (plus:SI (reg:SI 3 %r3)
                (const_int 15 [0xf])) 1) 0)
    (mem/s:SI (plus:SI (reg:SI 3 %r3)
            (const_int 12 [0xc])) 1))

Your claim is that the paradoxical subreg allows us to pretend the bits
are anything that is convenient for the optimizer.  I claim we can't make
that assumption.  Let's pretend the memory in question has the value
0x12345678.  Plug it in (remembering byte loads zero extend, big endian)
and the hardware actually performs the following comparison:

(eq (0x00000078) (0x12345678)

Which is false.

However, combine treats this as

(eq (0x12345678) (0x12345678)

Which is true and combine optimizes away the comparison.

So, something is inconsistent.

jeff

  reply	other threads:[~2002-01-28 19:58 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-01-28 12:18 Richard Kenner
2002-01-28 12:47 ` law [this message]
2002-01-28 14:53 ` law
2002-01-29 10:31   ` Richard Earnshaw
  -- strict thread matches above, loose matches on Subject: below --
2002-01-28 15:21 Richard Kenner
2002-01-28 15:41 ` law
2002-01-28 13:25 Richard Kenner
2002-01-28 13:46 ` David Edelsohn
2002-01-28 15:20   ` law
2002-01-28 15:50     ` Geoff Keating
2002-01-28 12:47 Richard Kenner
2002-01-28 13:10 ` law
2002-01-28 12:03 Richard Kenner
2002-01-28 12:15 ` law
2002-01-28 11:36 law
2002-01-28 11:50 ` Richard Henderson
2002-01-28 11:58   ` law
2002-01-28 12:05     ` Richard Henderson
2002-01-28 12:09       ` law
2002-01-28 12:39         ` Richard Henderson
2002-01-28 13:03           ` law
2002-01-28 13:18             ` Richard Henderson
2002-01-28 14:25             ` Michael Matz
2002-01-28 12:15 ` Michael Matz
2002-01-28 15:41 ` Jim Wilson
2002-01-29  1:57   ` Jim Wilson
2002-01-29 10:55   ` Richard Earnshaw

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=16847.1012247749@porcupine.cygnus.com \
    --to=law@redhat.com \
    --cc=gcc@gcc.gnu.org \
    --cc=kenner@vlsi1.ultra.nyu.edu \
    /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).