More on type sizes

More on type sizes

[Richard Kenner]

Now that I think about it, why do we need TYPE_SIZE *at all*?  The
only place we currently allow a size not to be a multiple of
BITS_PER_UNIT is the DECL_SIZE of a bitfield.  At some point, it would
indeed be nice to support such things as bit-packed arrays, where we
actually *do* have a type whose size is, say, 1 bit, but in that case
what would TYPE_SIZE_UNIT mean?

So I'm even more confused about the basics of what's trying to be
acomplished here.

Re: More on type sizes

[Joern Rennecke]

> Now that I think about it, why do we need TYPE_SIZE *at all*?  The
> only place we currently allow a size not to be a multiple of
> BITS_PER_UNIT is the DECL_SIZE of a bitfield.  At some point, it would
> indeed be nice to support such things as bit-packed arrays, where we
> actually *do* have a type whose size is, say, 1 bit, but in that case
> what would TYPE_SIZE_UNIT mean?

When a size is caluclated in bytes, we want to use TYPE_SIZE so that we
get the expected overlow effects.
When a size is calculated in bits, we don't want them.
Note that not only the size, but also the offset of a bitfield has to
be expressed in single bits - unless we want to use a representation
as sum of a multiple of BITS_PER_UNIT plus a single-bit count that
is smaller than BITS_PER_UNIT.

The original problem that propted the introduction of bitsizetype
was actually not a 32 bit compilation, but a 32->16 bit cross compilation.
The way this 'worked' was so that a structure could not be as large as
4 KB.

Re: More on type sizes

[Joern Rennecke]

P.S.: Chill uses bit arrays. For these, the elements have a TYPE_SIZE
(of one), but no TYPE_SIZE_UNIT.
Incidentally, the TYPE_SIZE of these elements is integer_size_node, which
is still wrong, since it has integer_type_node as type - this should be
converted to bitsizetype.

More on type sizes

[Richard Kenner]

Now that I think about it, why do we need TYPE_SIZE *at all*?  The
only place we currently allow a size not to be a multiple of
BITS_PER_UNIT is the DECL_SIZE of a bitfield.  At some point, it would
indeed be nice to support such things as bit-packed arrays, where we
actually *do* have a type whose size is, say, 1 bit, but in that case
what would TYPE_SIZE_UNIT mean?

So I'm even more confused about the basics of what's trying to be
acomplished here.

Re: More on type sizes

[Joern Rennecke]

> Now that I think about it, why do we need TYPE_SIZE *at all*?  The
> only place we currently allow a size not to be a multiple of
> BITS_PER_UNIT is the DECL_SIZE of a bitfield.  At some point, it would
> indeed be nice to support such things as bit-packed arrays, where we
> actually *do* have a type whose size is, say, 1 bit, but in that case
> what would TYPE_SIZE_UNIT mean?

When a size is caluclated in bytes, we want to use TYPE_SIZE so that we
get the expected overlow effects.
When a size is calculated in bits, we don't want them.
Note that not only the size, but also the offset of a bitfield has to
be expressed in single bits - unless we want to use a representation
as sum of a multiple of BITS_PER_UNIT plus a single-bit count that
is smaller than BITS_PER_UNIT.

The original problem that propted the introduction of bitsizetype
was actually not a 32 bit compilation, but a 32->16 bit cross compilation.
The way this 'worked' was so that a structure could not be as large as
4 KB.

Re: More on type sizes

[Joern Rennecke]

P.S.: Chill uses bit arrays. For these, the elements have a TYPE_SIZE
(of one), but no TYPE_SIZE_UNIT.
Incidentally, the TYPE_SIZE of these elements is integer_size_node, which
is still wrong, since it has integer_type_node as type - this should be
converted to bitsizetype.

Re: More on type sizes

[Per Bothner]

kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:

> It's interesting that Chill allows that.  In Ada (and I though Chill
> and Ada had some common heritage), the bounds of *any* array, whether
> empty or not, much be values in the index type.

By definition, the bounds of an empty array cannot be in the index
type - *if* you define index type as the type the indexes can range over.

> Can you say more about the typing rules of Chill in this area?

They are somewhat unusual, and I'm rather rusty on them, so I'd
rather pass.  (I don't have time to re-"grok" the spec.)
--
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

Re: More on type sizes

[Richard Kenner]

    >     We had to go through various contortions dealing with (say) a
    >     TYPE_MAX_VALUE of -1.  
    > 
    > I don't see why.

    For example if the index type is defined as a sub-type of an
    unsigned integer type.  In that case, -1 one is not in the
    index type, and in fact TYPE_MAX_VALUE is undefined.  

It's interesting that Chill allows that.  In Ada (and I though Chill
and Ada had some common heritage), the bounds of *any* array, whether
empty or not, much be values in the index type.

In Ada, if I have

	type Index is 20 .. 30;
	type Arr is array (Index range <>) of Character;

I can have members of type Arr that have bounds 30..29, 20..10, or 10..5
(all of which are empty), but *not* 31..30, since 31 is not a member of its
index type.

Can you say more about the typing rules of Chill in this area?

But my feeling is that if indeed a bound of Chill array can be outside the
bounds of its index type, then the index type actually in the tree needs to
be a different type, one that can contain all the values that are permitted
to be in the type.  That seems, to me, the cleanest approach, by far.

Re: More on type sizes

[Per Bothner]

kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:

>     We had to go through various contortions dealing with (say) a
>     TYPE_MAX_VALUE of -1.  
> 
> I don't see why.

For example if the index type is defined as a sub-type of an
unsigned integer type.  In that case, -1 one is not in the
index type, an din fact TYPE_MAX_VALUE is undefined.  Also,
see below.

>     It's been a while since I worked on this, so I'm rather rusty on the
>     issues.  One problem I seem to remember is that we wanted:
>       TREE_TYPE (TYPE_MIN_VALUE (T)) == T
>       TREE_TYPE (TYPE_MAX_VALUE (T)) == T
> 
> I'd have expected
> 
> 	TREE_TYPE (TYPE_MIN_VALUE (T)) to be TREE_TYPE (T)
> 
> in most cases.  Why do you want the former?

It's been a while, but I recall one reason was that Chill has
routines LOWER(T) and UPPER(T), and the return type of
LOWER(T) and UPPER(T) is T.  (I think;  I just glanced at
the Chill specification, but I am no longer very fluent
reading it!)
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

Re: More on type sizes

[Joern Rennecke]

>     P.S.: Chill uses bit arrays. For these, the elements have a TYPE_SIZE
>     (of one), but no TYPE_SIZE_UNIT.  
> 
> What code handles these?  Other languages (such as Ada) could benefit from
> that, and I'd like to support it fully sometime, but what code handles it?

I just spotted this bit in stor-layout.c:layout_type :

            /* Special handling for arrays of bits (for Chill).  */
            element_size = TYPE_SIZE (element);
            if (TYPE_PACKED (type) && INTEGRAL_TYPE_P (element))
              {
                HOST_WIDE_INT maxvalue
                  = TREE_INT_CST_LOW (TYPE_MAX_VALUE (element));
                HOST_WIDE_INT minvalue
                  = TREE_INT_CST_LOW (TYPE_MIN_VALUE (element));

                if (maxvalue - minvalue == 1
                    && (maxvalue == 1 || maxvalue == 0))
                  element_size = integer_one_node;
              }

>     Incidentally, the TYPE_SIZE of these elements is integer_size_node,
>     which is still wrong, since it has integer_type_node as type - this
>     should be converted to bitsizetype.
> 
> Yes, that's certainly wrong.  How did it happen?  Does the front end set
> TYPE_SIZE?  That almost always sounds wrong to me: only layout_type
> should be setting it.

layout_type does, see above.

Re: More on type sizes

[Per Bothner]

kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:

>     Chill doesn't generate ARRAY_REF for bit arrays/string.  Instead, it
>     generates PACKED_ARRAY_REF, which is defined in ch/ch-tree.def.
> 
> Hmm... I don't much like the idea of making a type in the
> language-independent code which only language-specific code can
> handle.  My feeling is that if the only things which can process a
> type are language-specific, then the type should be as well.

I agree and disagree.  The PACKED_ARRAY_REF should be subsumed by the
language-independent ARARY_REF, and the language-independent code
should handle packed arrays properly.  However, we didn't have the
time or expertise to do it properly, plus give that the Chill front-end
at that time was not part of the public sources we wanted to minimize
changes to the public sources.  (That is not the best approach, I agree.)
But even so, since the concept of a "packed array" is not language
specific, there is no point in *removing* that concept from the
language-independent code, even if the support is incomplete.
> 
> Also, why is a function call used in ch/expr.c?  Isn't it easy enough
> to open-code the one-bit case?

It gets a bit hairy when you have a dynamic bit index in a dynamically-sized
bit array, and also want to check for out-of-range.  Still, I agree the
best solution is to open-code the indexing.

> I don't follow here.  Please define "empty range" and give me an example.

An empty range is (for example) a string or array of length zero.
We had to go through various contortions dealing with (say) a
TYPE_MAX_VALUE of -1.  It's been a while since I worked on this,
so I'm rather rusty on the issues.  One problem I seem to remember 
is that we wanted:
  TREE_TYPE (TYPE_MIN_VALUE (T)) == T
  TREE_TYPE (TYPE_MAX_VALUE (T)) == T
This provided the necessary semantics, at least for Chill.
However, it doesn't really work for empty ranges, especially
when ranges can be dynamic.

Anyway, it's been so long I thought about this, I'm no longer
sure about it, and I doubt that I can convince anyone there is a
real problem *and* that it is worth fixing (especially when I'm
not even sure myself), so I'm going try to drop the issue.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

Re: More on type sizes

[Richard Kenner]

    P.S.: Chill uses bit arrays. For these, the elements have a TYPE_SIZE
    (of one), but no TYPE_SIZE_UNIT.  

What code handles these?  Other languages (such as Ada) could benefit from
that, and I'd like to support it fully sometime, but what code handles it?

    Incidentally, the TYPE_SIZE of these elements is integer_size_node,
    which is still wrong, since it has integer_type_node as type - this
    should be converted to bitsizetype.

Yes, that's certainly wrong.  How did it happen?  Does the front end set
TYPE_SIZE?  That almost always sounds wrong to me: only layout_type
should be setting it.

Re: More on type sizes

[Per Bothner]

kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:

> No, I meant what code handles generating code for ARRAY_REF of such
> types?   We shouldn't be making types that we can't generate code for!

Chill doesn't generate ARRAY_REF for bit arrays/string.
Instead, it generates PACKED_ARRAY_REF, which is defined in
ch/ch-tree.def.

I mentioned before, but this may be the right time to do so again:
The macro TYPE_MAX_VALUE is mis-designed, because it does not work
well for empty ranges.  It would be better to use TYPE_MIN_VALUE
having the value of the appropriate type, and replace TYPE_MAX_VALUE
by a new macro called something like TYPE_RANGE_SIZE.

The invariant is that all instances of TYPE_MAX_VALUE(x)
would be replaced by the sum of TYPE_MIN_VALUE and TYPE_RANGE_SIZE.
However, while the type of TYPE_MAX_VALUE is that of the range type
(except in the case of empty ranges!), the type of TYPE_RANGE_SIZE
is the appropriate size type.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

Re: More on type sizes

[Richard Kenner]

    Chill doesn't generate ARRAY_REF for bit arrays/string.  Instead, it
    generates PACKED_ARRAY_REF, which is defined in ch/ch-tree.def.

Hmm... I don't much like the idea of making a type in the
language-independent code which only language-specific code can
handle.  My feeling is that if the only things which can process a
type are language-specific, then the type should be as well.

Also, why is a function call used in ch/expr.c?  Isn't it easy enough
to open-code the one-bit case?

    I mentioned before, but this may be the right time to do so again: The
    macro TYPE_MAX_VALUE is mis-designed, because it does not work well
    for empty ranges.  It would be better to use TYPE_MIN_VALUE having the
    value of the appropriate type, and replace TYPE_MAX_VALUE by a new
    macro called something like TYPE_RANGE_SIZE.

    The invariant is that all instances of TYPE_MAX_VALUE(x)
    would be replaced by the sum of TYPE_MIN_VALUE and TYPE_RANGE_SIZE.
    However, while the type of TYPE_MAX_VALUE is that of the range type
    (except in the case of empty ranges!), the type of TYPE_RANGE_SIZE
    is the appropriate size type.

I don't follow here.  Please define "empty range" and give me an example.

For Ada, when either bound is variable, TYPE_MAX_VALUE is a MAX_EXPR to
handle the empty cases (you can have arrays with bounds 0 .. -100 in Ada
and it is *not* the same as an array with bounds of 0 ... -99, though both
have the same size, 0 bytes).

Re: More on type sizes

[Richard Kenner]

    When a size is caluclated in bytes, we want to use TYPE_SIZE so that we
    get the expected overlow effects.
    When a size is calculated in bits, we don't want them.

Yes, I understand that, so let me rephrase my question: when do we want the
size of a type in bits?

    Note that not only the size, but also the offset of a bitfield has to
    be expressed in single bits - unless we want to use a representation
    as sum of a multiple of BITS_PER_UNIT plus a single-bit count that is
    smaller than BITS_PER_UNIT.

Well, we always used to do that, but the problem is that I believe this
calculation is now being done in "mixed mode": some in sizetype and some
in bitsizetype.  But the definition of DECL_FIELD_BITPOS is in
bitsizetype, so the calculation, on a 32-bit machine, will be done in 64 bits
if the value is a variable.

So I think we either have to always view it as a PLUS_EXPR of MULT_EXPR
of a CONVERT_EXPR of a sizetype vaule and a constant in bitsizetype (which I
think is a mess) or have two fields: DECL_POSITION, which is the position
in bytes (in sizetype) and a DECL_FIELD_BITPOS, which is a bitsizetype value
(currently always a constant less than BITS_PER_UNIT) and gets added to
DECL_POSITION after the appropriate multiplication and conversion.  I think
the latter is the best approach.  What do others think?

Re: More on type sizes

[Richard Kenner]

    > What code handles these?  Other languages (such as Ada) could benefit
    > from that, and I'd like to support it fully sometime, but what code
    > handles it?

    I just spotted this bit in stor-layout.c:layout_type :

No, I meant what code handles generating code for ARRAY_REF of such
types?   We shouldn't be making types that we can't generate code for!

Re: More on type sizes

[Richard Kenner]

    The PACKED_ARRAY_REF should be subsumed by the language-independent
    ARARY_REF, and the language-independent code should handle packed
    arrays properly.  ...  But even so, since the concept of a "packed
    array" is not language specific, there is no point in *removing* that
    concept from the language-independent code, even if the support is
    incomplete.

I agree.  I wasn't proposing *removing* it, just commenting that I
view the present situation as somewhat unfortunate, mostly as a way to
discourage it occuring aain.  I suspect we both agree on this.

    It gets a bit hairy when you have a dynamic bit index in a
    dynamically-sized bit array, and also want to check for out-of-range.
    Still, I agree the best solution is to open-code the indexing.

The issue of range changes is one that I see very differently from the
indexing itself.  Range checks almost always need to be done by the front
end since the failure of a range check is language-specific.  But range
checks can also often be deleted (consider a loop over the bounds of the
array, a common case), so the main issue for me is the indexing itself.

    An empty range is (for example) a string or array of length zero.

OK.

    We had to go through various contortions dealing with (say) a
    TYPE_MAX_VALUE of -1.  

I don't see why.

    It's been a while since I worked on this, so I'm rather rusty on the
    issues.  One problem I seem to remember is that we wanted:
      TREE_TYPE (TYPE_MIN_VALUE (T)) == T
      TREE_TYPE (TYPE_MAX_VALUE (T)) == T

I'd have expected

	TREE_TYPE (TYPE_MIN_VALUE (T)) to be TREE_TYPE (T)

in most cases.  Why do you want the former?

Re: More on type sizes

[Richard Kenner]

    The PACKED_ARRAY_REF should be subsumed by the language-independent
    ARARY_REF, and the language-independent code should handle packed
    arrays properly.  ...  But even so, since the concept of a "packed
    array" is not language specific, there is no point in *removing* that
    concept from the language-independent code, even if the support is
    incomplete.

I agree.  I wasn't proposing *removing* it, just commenting that I
view the present situation as somewhat unfortunate, mostly as a way to
discourage it occuring aain.  I suspect we both agree on this.

    It gets a bit hairy when you have a dynamic bit index in a
    dynamically-sized bit array, and also want to check for out-of-range.
    Still, I agree the best solution is to open-code the indexing.

The issue of range changes is one that I see very differently from the
indexing itself.  Range checks almost always need to be done by the front
end since the failure of a range check is language-specific.  But range
checks can also often be deleted (consider a loop over the bounds of the
array, a common case), so the main issue for me is the indexing itself.

    An empty range is (for example) a string or array of length zero.

OK.

    We had to go through various contortions dealing with (say) a
    TYPE_MAX_VALUE of -1.  

I don't see why.

    It's been a while since I worked on this, so I'm rather rusty on the
    issues.  One problem I seem to remember is that we wanted:
      TREE_TYPE (TYPE_MIN_VALUE (T)) == T
      TREE_TYPE (TYPE_MAX_VALUE (T)) == T

I'd have expected

	TREE_TYPE (TYPE_MIN_VALUE (T)) to be TREE_TYPE (T)

in most cases.  Why do you want the former?

Re: More on type sizes

[Per Bothner]

kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:

>     Chill doesn't generate ARRAY_REF for bit arrays/string.  Instead, it
>     generates PACKED_ARRAY_REF, which is defined in ch/ch-tree.def.
> 
> Hmm... I don't much like the idea of making a type in the
> language-independent code which only language-specific code can
> handle.  My feeling is that if the only things which can process a
> type are language-specific, then the type should be as well.

I agree and disagree.  The PACKED_ARRAY_REF should be subsumed by the
language-independent ARARY_REF, and the language-independent code
should handle packed arrays properly.  However, we didn't have the
time or expertise to do it properly, plus give that the Chill front-end
at that time was not part of the public sources we wanted to minimize
changes to the public sources.  (That is not the best approach, I agree.)
But even so, since the concept of a "packed array" is not language
specific, there is no point in *removing* that concept from the
language-independent code, even if the support is incomplete.
> 
> Also, why is a function call used in ch/expr.c?  Isn't it easy enough
> to open-code the one-bit case?

It gets a bit hairy when you have a dynamic bit index in a dynamically-sized
bit array, and also want to check for out-of-range.  Still, I agree the
best solution is to open-code the indexing.

> I don't follow here.  Please define "empty range" and give me an example.

An empty range is (for example) a string or array of length zero.
We had to go through various contortions dealing with (say) a
TYPE_MAX_VALUE of -1.  It's been a while since I worked on this,
so I'm rather rusty on the issues.  One problem I seem to remember 
is that we wanted:
  TREE_TYPE (TYPE_MIN_VALUE (T)) == T
  TREE_TYPE (TYPE_MAX_VALUE (T)) == T
This provided the necessary semantics, at least for Chill.
However, it doesn't really work for empty ranges, especially
when ranges can be dynamic.

Anyway, it's been so long I thought about this, I'm no longer
sure about it, and I doubt that I can convince anyone there is a
real problem *and* that it is worth fixing (especially when I'm
not even sure myself), so I'm going try to drop the issue.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

Re: More on type sizes

[Richard Kenner]

    Chill doesn't generate ARRAY_REF for bit arrays/string.  Instead, it
    generates PACKED_ARRAY_REF, which is defined in ch/ch-tree.def.

Hmm... I don't much like the idea of making a type in the
language-independent code which only language-specific code can
handle.  My feeling is that if the only things which can process a
type are language-specific, then the type should be as well.

Also, why is a function call used in ch/expr.c?  Isn't it easy enough
to open-code the one-bit case?

    I mentioned before, but this may be the right time to do so again: The
    macro TYPE_MAX_VALUE is mis-designed, because it does not work well
    for empty ranges.  It would be better to use TYPE_MIN_VALUE having the
    value of the appropriate type, and replace TYPE_MAX_VALUE by a new
    macro called something like TYPE_RANGE_SIZE.

    The invariant is that all instances of TYPE_MAX_VALUE(x)
    would be replaced by the sum of TYPE_MIN_VALUE and TYPE_RANGE_SIZE.
    However, while the type of TYPE_MAX_VALUE is that of the range type
    (except in the case of empty ranges!), the type of TYPE_RANGE_SIZE
    is the appropriate size type.

I don't follow here.  Please define "empty range" and give me an example.

For Ada, when either bound is variable, TYPE_MAX_VALUE is a MAX_EXPR to
handle the empty cases (you can have arrays with bounds 0 .. -100 in Ada
and it is *not* the same as an array with bounds of 0 ... -99, though both
have the same size, 0 bytes).

Re: More on type sizes

[Per Bothner]

kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:

> No, I meant what code handles generating code for ARRAY_REF of such
> types?   We shouldn't be making types that we can't generate code for!

Chill doesn't generate ARRAY_REF for bit arrays/string.
Instead, it generates PACKED_ARRAY_REF, which is defined in
ch/ch-tree.def.

I mentioned before, but this may be the right time to do so again:
The macro TYPE_MAX_VALUE is mis-designed, because it does not work
well for empty ranges.  It would be better to use TYPE_MIN_VALUE
having the value of the appropriate type, and replace TYPE_MAX_VALUE
by a new macro called something like TYPE_RANGE_SIZE.

The invariant is that all instances of TYPE_MAX_VALUE(x)
would be replaced by the sum of TYPE_MIN_VALUE and TYPE_RANGE_SIZE.
However, while the type of TYPE_MAX_VALUE is that of the range type
(except in the case of empty ranges!), the type of TYPE_RANGE_SIZE
is the appropriate size type.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

Re: More on type sizes

[Richard Kenner]

    > What code handles these?  Other languages (such as Ada) could benefit
    > from that, and I'd like to support it fully sometime, but what code
    > handles it?

    I just spotted this bit in stor-layout.c:layout_type :

No, I meant what code handles generating code for ARRAY_REF of such
types?   We shouldn't be making types that we can't generate code for!

Re: More on type sizes

[Joern Rennecke]

>     P.S.: Chill uses bit arrays. For these, the elements have a TYPE_SIZE
>     (of one), but no TYPE_SIZE_UNIT.  
> 
> What code handles these?  Other languages (such as Ada) could benefit from
> that, and I'd like to support it fully sometime, but what code handles it?

I just spotted this bit in stor-layout.c:layout_type :

            /* Special handling for arrays of bits (for Chill).  */
            element_size = TYPE_SIZE (element);
            if (TYPE_PACKED (type) && INTEGRAL_TYPE_P (element))
              {
                HOST_WIDE_INT maxvalue
                  = TREE_INT_CST_LOW (TYPE_MAX_VALUE (element));
                HOST_WIDE_INT minvalue
                  = TREE_INT_CST_LOW (TYPE_MIN_VALUE (element));

                if (maxvalue - minvalue == 1
                    && (maxvalue == 1 || maxvalue == 0))
                  element_size = integer_one_node;
              }

>     Incidentally, the TYPE_SIZE of these elements is integer_size_node,
>     which is still wrong, since it has integer_type_node as type - this
>     should be converted to bitsizetype.
> 
> Yes, that's certainly wrong.  How did it happen?  Does the front end set
> TYPE_SIZE?  That almost always sounds wrong to me: only layout_type
> should be setting it.

layout_type does, see above.

Re: More on type sizes

[Richard Kenner]

    P.S.: Chill uses bit arrays. For these, the elements have a TYPE_SIZE
    (of one), but no TYPE_SIZE_UNIT.  

What code handles these?  Other languages (such as Ada) could benefit from
that, and I'd like to support it fully sometime, but what code handles it?

    Incidentally, the TYPE_SIZE of these elements is integer_size_node,
    which is still wrong, since it has integer_type_node as type - this
    should be converted to bitsizetype.

Yes, that's certainly wrong.  How did it happen?  Does the front end set
TYPE_SIZE?  That almost always sounds wrong to me: only layout_type
should be setting it.

Re: More on type sizes

[Richard Kenner]

    When a size is caluclated in bytes, we want to use TYPE_SIZE so that we
    get the expected overlow effects.
    When a size is calculated in bits, we don't want them.

Yes, I understand that, so let me rephrase my question: when do we want the
size of a type in bits?

    Note that not only the size, but also the offset of a bitfield has to
    be expressed in single bits - unless we want to use a representation
    as sum of a multiple of BITS_PER_UNIT plus a single-bit count that is
    smaller than BITS_PER_UNIT.

Well, we always used to do that, but the problem is that I believe this
calculation is now being done in "mixed mode": some in sizetype and some
in bitsizetype.  But the definition of DECL_FIELD_BITPOS is in
bitsizetype, so the calculation, on a 32-bit machine, will be done in 64 bits
if the value is a variable.

So I think we either have to always view it as a PLUS_EXPR of MULT_EXPR
of a CONVERT_EXPR of a sizetype vaule and a constant in bitsizetype (which I
think is a mess) or have two fields: DECL_POSITION, which is the position
in bytes (in sizetype) and a DECL_FIELD_BITPOS, which is a bitsizetype value
(currently always a constant less than BITS_PER_UNIT) and gets added to
DECL_POSITION after the appropriate multiplication and conversion.  I think
the latter is the best approach.  What do others think?