Re: HI to SI mode miss conversion on MIPS.

[Jeffrey A Law <law at cygnus dot com>]

 In message <20000215140214A.machida@sm.sony.co.jp>you write:
  > 
  > 
  > From: Jeffrey A Law <law@cygnus.com>
  > Subject: Re: HI to SI mode miss conversion on MIPS. 
  > Date: Sun, 13 Feb 2000 14:02:57 -0700
  > 
  > > Maybe I'm just dense today, but I don't see how these two expressions are
  > > not equivalent:
  > > 
  > > (and:SI (ashift:SI (reg:SI 108)
  > >          (const_int 8 [0x8]))
  > >     (const_int 65280 [0xff00]))
  > > 
  > > (subreg:HI (ashift:SI (reg:SI 108)
  > >         (const_int 8 [0x8])) 0)
  > > 
  > > 
  > > The first is X in the code fragment you posted.  The second is the return
  > > value from force_to_mode.  Note how we've wrapped the expression in a sub
  > reg
  > > which indicates that we don't care about bits outside of HImode.
  > > 
  > > jeff
  > 
  > Try to explain, but I may misunderstand the problem because of 
  > lack of my knowledge about combination-phase. Please let me know, if 
  > so.
  > 
  > Suppose that 108's nozero_bits is 0xffffffff and those X is set to
  > some SI register.
  > 
  > (set (reg:SI 111) (and:SI (ashift:SI (reg:SI 108)
  > 				(const_int 8 [0x8]))
  > 			(const_int 65280 [0xff00]))
  > 
  > (set (reg:SI 111)  (subreg:HI (ashift:SI (reg:SI 108)
  > 				(const_int 8 [0x8])) 0)
  > 
  > The nonzero_bits of 111 correspoding to the first X is 0x0000ff00,
  > but, the second is 0xffffff00. 
  > I don't know force_mode() should preserve nonzero_bits or not.
  > But, I guess the problem is cause by ignoring nonzero_bits
  > information somewhere I can't point out.
But the (subreg:HI) indicates that we don't actually care about the upper
16 bits.  ie, they're never used/examined.

So, even if nonzero_bits for reg111 in the second case is 0xffffff00 we do
not care because we know that the upper 16bits are completely unimportant
for the proper execution of the program.

jeff