On 07/02/11 00:11, Joseph S. Myers wrote: > 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.
As far as I can tell, type_for_size is used in quite a few places for optimizations. I've certainly seen intPI_type being used for 40-bit bitfields, and also for bitsize-types used in variable-length array calculations. There's a surprising amount of coverage in the testsuite already using these two features. I suspect we'd lose that capability if we don't extend this function. > 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. See above. I think this loses optimization opportunities. > * 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. I'll think about this next week. Bernd
