comp_type_attributes

[Marc Glisse]

On Tue, 17 Jan 2012, Ian Lance Taylor wrote:

> When COMP_TYPE_ATTRIBUTES was introduced, it was a macro which could be
> set in tm.h to check type attributes.
>
> Fri May  6 14:05:00 1994  Stephen R. van den Berg  (berg@pool.informatik.rwth-aachen.de)
>
> 	* tree.h (TYPE_ATTRIBUTES): New macro.
> 	(struct tree_type): attributes, new field.
> 	(precision): Move this field up for better alignment.
> 	(attribute_list_{equal,contained}): Prototype for new functions.
> 	(build_type_attribute_variant): Prototype for new function.
> 	* c-parse.in: Rewrite attribute parsing; update the expected
> 	conflicts and state numbers.
> 	* tree.c (TYPE_HASH): Move definition to top of file.
> 	(make_node): Add support for SET_DEFAULT_TYPE_ATTRIBUTES.
> 	(build_type_attribute_variant): New function.
> 	(type_hash_lookup): Check if the attributes match.
> 	(attribute_list_{equal,contained}): New functions.
> 	* c-typeck.c (common_type): Add attribute merging.
> 	(comp_types): Use COMP_TYPE_ATTRIBUTES macro.
> 	* print-tree.c (print_node): Print attributes.
> 	* c-common.c (decl_attributes): Move the attribute
> 	recognition and rejection here from c-parse.in.
> 	(decl_attributes): Use VALID_MACHINE_ATTRIBUTE macro.
>
> This was before there was a affects_type_identity field.  Given that,
> and given the assumption that most attributes were backend specific, a
> default of 1 made sense.
>
> The default has carried forward since then.  The affects_type_identity
> field was added in March 2011 as part of the fix for PR 12171, in order
> to produce a better error message.  Kai followed with a change to test
> affects_type_identity in the new comp_type_attributes function:
>
> http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01318.html
>
> At that point I think it would have made sense to change the default of
> TARGET_COMP_TYPE_ATTRIBUTES.  Or, it should be renamed, since it is no
> longer simply serving as a comparison, but is now serving to handle the
> special case for which it was introduced, x86 calling convention
> attributes.
>
> So, no real answers here, but I agree that this is an area that could
> use some cleanup.

Thanks a lot for this detailed analysis, which explains much. I definitely 
should have looked at the history (though it wouldn't have been as clear 
as your explanation).

I am not sure what the right approach is. The current middle-end code as a 
speed optimization is strange. Other than that, there really is a problem 
only if we want to allow attributes that affect the type in other places 
than targets. If we don't, we can leave things as they are (possibly with 
a rename/comment). If we do, we would somehow need a way to specify which 
attributes are handled by the targets, either by adding a new property to 
attributes, or by making TARGET_COMP_TYPE_ATTRIBUTES return the attributes 
it doesn't know (or forward them to some generic comparison function).

The example I am considering is the extern "C" property of some function 
types in C++. It is a calling convention specifier, not specific to any 
target, although the current ABI says it has no effect. In my prototype 
patch for bug 2316, I reuse the minval field to store this property, and I 
then need to adapt quite a few functions to preserve it. Using an 
attribute seems to make sense and would reuse more existing mechanisms 
(though it may have drawbacks too).

-- 
Marc Glisse