This is the mail archive of the
mailing list for the GCC project.
Re: [RFA/dwarf-2] Avoid unnecessary subrange_type (3/3)
> 1) Why do the affected types look like subrange types to begin with?
> Why do they have a TREE_TYPE?
It turns out that this is a specificity of Ada required by the Ada
language. The following comment for proc Create_Unconstrained_Base_Type
in ada/cstand.adb reveals the necessity of the type/subtype pair.
-- The predefined signed integer types are constrained subtypes which
-- must have a corresponding unconstrained base type. This type is almost
-- useless. The only place it has semantics is Subtypes_Statically_Match.
-- Consequently, we arrange for it to be identical apart from the setting
-- of the constrained bit. This routine takes an entity E for the Type,
-- copies it to estabish the base type, then resets the Ekind of the
-- original entity to K (the Ekind for the subtype). The Etype field of
-- E is set by the call (to point to the created base type entity), and
-- also the Is_Constrained flag of E is set.
-- To understand the exact requirement for this, see RM 3.5.4(11) which
-- makes it clear that Integer, for example, is constrained, with the
-- constraint bounds matching the bounds of the (unconstrained) base
-- type. The point is that Integer and Integer'Base have identical
-- bounds, but do not statically match, since a subtype with constraints
-- never matches a subtype with no constraints.
I double check for other languages such as C, and "long long int" tree
do not have a TREE_TYPE.
That suggests the addition of an is_ada() quick-check for the CU language
before going through the rest of the test, to limit this base type
detection to Ada types. However, I think that this test is applicable to
all languages; so eventhough I do not know of example of base types from
other languages being built that way, doing this check can only help.
> > if (TREE_CODE (type) == TREE_CODE (subtype)
> > && int_size_in_bytes (type) == int_size_in_bytes (subtype)
> > && TYPE_MIN_VALUE (type) != NULL
> > && TYPE_MIN_VALUE (subtype) != NULL
> > && tree_int_cst_equal (TYPE_MIN_VALUE (type), TYPE_MIN_VALUE (subtype))
> > && TYPE_MAX_VALUE (type) != NULL
> > && TYPE_MAX_VALUE (subtype) != NULL
> > && tree_int_cst_equal (TYPE_MAX_VALUE (type), TYPE_MAX_VALUE (subtype)))
> In the cases you're interested in, are TYPE_SIZE, TYPE_MIN_VALUE and
> TYPE_MAX_VALUE different INTEGER_CSTs for the two types, or can you just
> compare pointers there, too? TYPE_SIZE should definitely be the same node,
> since we canonicalize sizetype INTEGER_CSTs.
Unfortunately, for a reason I don't understand yet, the TYPE_SIZE nodes
are not identical for type "integer". For now, I suggest keeping the
size check as it is now, with a dated-fixme if necessary.
As for the MIN and MAX values, they are not the same nodes. So we
can't compare the pointers directly.
Shall I go ahead, complete the testing for the following condition:
if (TREE_CODE (type) == TREE_CODE (subtype)
&& int_size_in_bytes (type) == int_size_in_bytes (subtype)
&& TYPE_MIN_VALUE (type) != NULL
&& TYPE_MIN_VALUE (subtype) != NULL
&& tree_int_cst_equal (TYPE_MIN_VALUE (type), TYPE_MIN_VALUE (subtype))
&& TYPE_MAX_VALUE (type) != NULL
&& TYPE_MAX_VALUE (subtype) != NULL
&& tree_int_cst_equal (TYPE_MAX_VALUE (type), TYPE_MAX_VALUE (subtype)))
/* The type and its subtype have the same representation. If in
addition the two types also have the same name, then the given
type is not a subrange type, but rather a plain base type. */
tree type_name = TYPE_NAME (type);
tree subtype_name = TYPE_NAME (subtype);
if (type_name != NULL && TREE_CODE (type_name) == TYPE_DECL)
type_name = DECL_NAME (type_name);
if (subtype_name != NULL && TREE_CODE (subtype_name) == TYPE_DECL)
subtype_name = DECL_NAME (subtype_name);
if (type_name == subtype_name)
and submit that?