Re: Size changes, round 1

[Mark Mitchell <mark at codesourcery dot com>]

  Unfortunately, Ada is a language that needs both.  I don't know about
  Chill, but suspect it does as well from what I can see.

OK.

      I agree that the bit position needs to support bits, and might need to
      support a bit position up to, say, 2^35 on a 32-bit machine.  (If,
      say, you made a structure corresponding to the entire address space,
      which people sometimes do.)  But, again, we only need this in a
      FIELD_DECL -- not everywhere, as in your patch.

  Note that I didn't start this: the addition of TYPE_SIZE_UNIT did.  If we're
  going to keep that and do things consistently, we also need the fields I
  added.  If we don't have them, then we need to remove TYPE_SIZE_UNIT or
  replace it with something else.

I agree.  Your changes are indeed a consistent extension.  I'm not
sure we need them -- conceivable, this could be necessary for types
and not declarations.  But, it could also be necessary for both, and
I'm certainly willing to believe that the same rationales that caused
the introduction of TYPE_SIZE_UNIT would apply here as well.

  I must admit to being alittle annoyed that I raised the issue quite a while
  ago, left several weeks for discussion, there wasn't much, and now that I'm
  starting to implement the results of that discussion, *now* there's renewed
  interest in it.

I understand your frustruation.  The same thing has happenned to me a
few times.  I'm sorry I didn't notice the original discussion -- on a
busy day, I really can't read the hundred or so GCC messages and still
get much other work done!  This change caught my eye because it seems
to have broader engineering implications than most routine changes.

  Not exactly.  Some things need one and some need the other.  We always had
  places in the compiler that used the sizes in bytes and others that used by
  the size in bits.  The change to add TYPE_SIZE_UNIT (and my extension to it)
  simplify that code by only doing the conversion once.

True.

  I don't follow what you're trying to say here.  Front ends, in general, don't
  do much with type and decl sizes.

Well, some of them do.  And I expect they'll do more.  In particular,
the C++ front-end does quite a bit with these, and is about to do more
-- for example, we lay out run-time type information structures, and
do various manipulations to implement virtual function tables that
depend on manipulating DECL_SIZE/TYPE_SIZE.

      I think that if we're really going to do this, we should, at the very
      least, create a structure type:

	struct size_type { 
	  tree scaling_factor;
	  tree magnitude;
	};

      and a bunch of routines for manipulating these.  DECL_SIZE, TYPE_SIZE,
      etc. should return pointers to these things.  The C type-system would
      then prevent us from making some of the more obvious mistakes.  That
      would make me much more comfortable -- it's clean, and it prevents
      bugs.

  I don't see what you gain by this.  You really do want both values for each
  type for the reasons that were given when TYPE_SIZE_UNIT was added and
  if you have those, DECL_SIZE_UNIT is just a logical extension.  If you
  have just one size with a scale factor, you only gain one of the benefits
  of the original change.

Perhaps I wasn't clear.  I meant this to be semantically equivalent to
your change.  With your change, everywhere we use to have an _SIZE
tree node, we now have two: an _SIZE and an _SIZE_UNIT.  So, that
suggests that what we really mean is that a `size' is a data structure
containing two tree nodes: the magnitude and the scaling factor.  By
treating a `size' as an abstract type, we could help to eliminate the
bugs that will result from people accidentally adding two _SIZEs with
different _SIZE_UNITs, but not scaling, for example.  Basically, we
could gain all the ordinary benefits of an abstract data type by
treating sizes as such.

I think this is unquestionably better than the current state -- I'm
just trying to use the usual principles of type-safety to help keep us
out of trouble.  It's *exactly* as expressive as the current state.
(I did suggest some other options that were less expressive.)
Concretely, I'm proposing that tree_decl look (roughly) like:

  struct tree_decl {
    char x[sizeof (tree_common)];
    ...
    size_type size;
    ...
  };

  #define DECL_SIZE(NODE) (node->decl.size);

Then, something like:

  /* Make the size of X the size of Y plus the size of Z.  

     Oops, this has a bug -- I forgot to check the scaling factor.  */
  DECL_SIZE (x) = fold (build (PLUS_EXPR,
	                       size_type_node,
			       DECL_SIZE (y),
			       DECL_SIZE (z)));

  
you would do:

  /* Look, ma, no bug!  */
  DECL_SIZE (x) = add_sizes (DECL_SIZE (y), DECL_SIZE (z));

    o What problem are you trying to solve?  Please articulate this
      clearly.

  The change to add TYPE_SIZE_UNIT was missing a number of important
  pieces: this is one and the other related to bit sizes.

Thanks for answering all of my questions.

I think my ADT suggestion would be a huge maintainability improvement,
and I hope that you will be willing to implement it before your next
round of fixes.  I'm sure it will reduce errors in the future, as well
as make the code more readable.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com