This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: paradoxical subreg problem


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]