Size changes, round 1

[Richard Kenner]

    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.

"necessary" is a strong word and I wouldn't use it.  Consistency is
certainly *one* motivation, but not the major one.  The issue is
FIELD_DECLs: I strongly beleive they need position in both bits and
bytes and that means that you need to have both forms of sizes
available in the FIELD_DECL to do the computation.  See below for what
I think you're missing here.

      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.  

I'd hope not.  I view laying out types as the sole purview of the back end and
view each time a front end has to muck with sizes as a failure of the
capabilities of our front-end interface.

    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'd suggest trying to find ways to do that using existing back-end
interfaces or adding what you need to that interface. This has been the
approach taken with Ada, for example.  Yes, it does do some of its own
mucking around with sizes and positions, but it's kept to a minimum.

    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.  

Now I see the major point you're missing!  _SIZE and _SIZE_UNIT don't
just have different *values*: they have different *types*.  The former
is bitsizetype, which is a 64-bit type on most machines, while the latter
is sizetype, which is a 32-bit type on most machines.

    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. 

We get that already by adding an abort to size_binop if both args are not
the same type.

    Basically, we could gain all the ordinary benefits of an abstract data
    type by treating sizes as such.

No, I don't think so.  Your proposal needs three pointers and only ends up
saving *one* format of the size, while what we have now uses *two* pointers
and has both forms of the type.

The issue, as I said, is variable-sized types, where you'd end up
doing lots of computations in 64 bits and having conversions between
32 and 64 bit values.  Consider a record whose first field is a variable-sized
array and whose subsequent fields are 2-bit bitfields.  the second of those
will have a bit position that's the sum of 2 plus 8 times the byte size of
the first field.  You *do not* want to do that in a 64-bit type.  This is
not an obscure case, at all, in Ada: it's very common in many appliations.

    It's *exactly* as expressive as the current state.  (I did suggest

No, not at all, since you only store *one* form of the size for each type:
either a 32-bit size in bytes or a 64-bit size in bits.

Keep in mind that it's not just sizes, but positions too.  And *those*
are the ones that get "mixed" if you don't keep byte and bit sizes
separate from the start.

    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.

See above for why I disagree.  It's no more safe than the present
situation and will cause much more expensive position and indexing
calculations.

This was a variant of one of the suggestions that came up in the original
discussion.

What do others think here?