This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: paradoxical subreg problem
- From: law at redhat dot com
- To: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- Cc: gcc at gcc dot gnu dot org
- Date: Mon, 28 Jan 2002 12:55:49 -0700
- Subject: Re: paradoxical subreg problem
- Reply-to: law at redhat dot com
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