Size changes, round 1

Mark Mitchell mark@codesourcery.com
Sun Feb 20 13:15:00 GMT 2000


  Mark Mitchell wrote:

  > Sometimes, of course, it's better to do a little hack, and reap
  > immediate benefits, than develop some grand new optimization.  So, I'm
  > not criticizing.  But, if better optimization will obviate then need
  > for TYPE_SIZE_UNIT, then I'm not sure we should be pushing this stuff
  > further into the compiler.

  But there still is the problem that - on a thoroughly 32-bit target like
  the ia32 - one cannot compile:

	PROGRAM HALLO
	DOUBLE PRECISION A(67108864)
	WRITE(*,*) "HALLO"
	END

  [ Of course, I'd love to explain that, for compiling this program,
    one needs a *real* computer - but I refrain ]

I understand.

BTW, the TYPE_SIZE/TYPE_SIZE_UNIT split doesn't fully fix that
problem, at least in the fully general case.  Imagine a type of size,
say, 2^30 + 103 bits.  We have to use TYPE_SIZE to represent it --
TYPE_SIZE_UNIT can't show the odd bits hanging off the end.  Now,
suppose we have a bunch of these laid end-to-end in a packed
structure/array.  We can overflow TYPE_SIZE (because we have too many
bits in the structure/array) but we still can't represent the right
number of bits in TYPE_SIZE_UNIT because the conglomerate has a few
stray bits in it.

The general solution is to have a way of representing numbers that
range from 0 to BITS_PER_UNIT * BIGGEST_NUMBER_OF_BYTES_ALLOWED.  We
don't have that, even with TYPE_SIZE/TYPE_SIZE_UNIT.
 
--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com


More information about the Gcc-patches mailing list