sign-extending smaller modes

[Jeffrey A Law]

  In message <200004121521.LAA01947@envy.delorie.com>you write:
  > 
  > I don't know why BITS_PER_WORD was being used; it doesn't always
  > correspond to the size of the type being converted, and isn't used in
  > any of the other logic in those areas.
Historical.  The code in question was trying to deal with a very specific
case where our RTL representation causes problems.

Consider the 32bit value (unsigned) -1 for a 32bit target and a 64bit host.

That can be represented as either 0x00000000ffffffff or 0xffffffffffffffff
at the RTL level.  Both are technically correct, though the second allows
us to write tests like INTVAL (x) == -1  and the right thing will happen.

The second also works better when printing operands.  If we try to print
the first representation as an integer we get 4294967295.  Opps.  Some
assemblers have the good sense to DTRT with such an operand, some don't.

Contrast that to the 2nd representation.  If we try to print it as an
integer we get "-1", which is what we want.  

Your change extends this concept to values which are not a full word for
the target.  I believe the specific port which caused you to look at this
is a 64bit port, but only has 32bit pointers (and thus we generate a
number of 32bit values via immed_double_const for use in SImode patterns.

Interestingly enough, if I install your change I can't bootstrap the
PA port, so there's something happening that we don't quite understand.

FWIW, I think your problem can just as easily be fixed by fixing the
MIPS backend.  ie, by sign extending constants in the SImode patterns from
32 to 64 bits you'll avoid the assembler complaint which originally lead
you to this problem.


  > 2000-04-12  DJ Delorie  <dj@cygnus.com>
  > 
  > 	* varasm.c (immed_double_const): sign-extend modes smaller
  > 	than the default machine mode also
  > 	* explow.c (trunc_int_for_mode): ditto
I haven't installed this since it's known to cause a bootstrap failure on
at least one platform.
jeff