On Fri, 1 Jul 2011, Bernd Schmidt wrote: > > * The global tree nodes for various modes are suspicious. Why are they > > needed at all? > > Do you mean only the PImode ones or also intQI_type_node etc.? These are > used to pick a suitable type in c_common_type_for_size.
All of them. > > * The c_common_type_for_size code using those nodes is suspicious. Front > > ends shouldn't care about modes like that. > > It doesn't care about the modes, it just picks a suitable one for a > given precision. Note that my patch does not introduce this mechanism, > it just extends it. I don't think anything would be worse without it being extended - these are generally places that would be improved by removing code for existing modes (maybe replaced by calls to build_nonstandard_integer_type if not already there) rather than adding it for more. Removing this code would require some thought, but I don't think it needs adding to. If logic for nonstandard precisions is needed and needs to do something other than call build_nonstandard_integer_type, a better approach might be a target-specific table (initialized by a target hook) of types to consider. Most targets never need to consider intQI_type_node etc. since those types all correspond to some standard type, so rather than having the global nodes the hook would be responsible for entering those types in the table. But since there are several such functions doing similar things, some thought should be given to avoiding duplication. * For nonstandard types c_common_type_for_size only requires a number of bits <= to the precision of the mode. I don't think it should matter that this would return a 64-bit type instead of a 40-bit one in some cases. * For c_common_type_for_mode, after checking standard types it should just use some table of types for different modes that get built on demand then cached. (Actually, put standard types there in appropriate order and then the function doesn't need to check them.) However, the code checking registered_builtin_types will probably suffice for now if you make the target register the types in some way. > > Check standard types, > > otherwise defer to something generic that loops over available types or > > modes or builds a type as needed. > > Please look at the code; this is exactly what is being done. The > function checks the standard types, and if it does not find one with an > exact match for the precision, it examines the available modes (exposed > through intQI_type_node etc.). There are better ways of iterating through modes than hardcoding a list. > > Targets should be able to define integer types and modes as needed - but > > changing target-independent code for a particular type indicates something > > is wrong; I wouldn't expect any more target-independent changes than have > > been associated with floating-point types such as __fp16, __float80 or > > __float128. > > That's because these all fall into the standard C type system of float, > double, long double. No, in general they are different from those types. > If you subtract out all the INT_LEAST40_TYPE etc. support, there really > aren't very many changes in the C frontend, and I think the remaining > ones are just the same ones we have for TImode - pretty much unavoidable > for properly supporting a new integer type that is exposed to > programmers. I'll resubmit such a patch in the hope that it'll look more I think more is needed for a type wider than the standard types than for one within the range of precisions of standard types. -- Joseph S. Myers jos...@codesourcery.com
