On 07/01/11 22:36, Joseph S. Myers wrote: > On Fri, 1 Jul 2011, Bernd Schmidt wrote: >> The idea here is that there is more than one target that supports 40 bit >> operations, so why shouldn't we have support for it in >> target-independent code and libgcc? It differs from QI/HI/SImode etc. in >> that the precision is known and not target-specific. > > Well, the idea of an integer mode with non-target-specific precision is > pretty unusual in GCC; normally they are defined as a multiple of QImode > (BITS_PER_UNIT).
It's unusual only in terms of integer modes. It's analogous to decimal float (where we also check targetm.scalar_mode_supported_p in the frontend to determine whether to support it) or fixed-point support (checked with targetm.fixed_point_supported_p, and the fixed-point modes are all defined with specified precisions). And even for integer modes, there's precedent with TI/__int128_t. > And the existence of this mode is apparently target-specific even if > its properties aren't. Yes. That's probably a good way to think about it. Again, the analogy would be decimal float or fixed-point. > * 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. > * 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. > 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.). > 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. > There's the odd target hook, and it's necessary to tell > libgcc what modes to build for (but in general you have a libgcc function > implementation that can be used for more than one mode, depending on the > properties of the types, rather than separate implementations per mode). > Just as __float80 and __float128 are target-specific types defined by > small amounts of target hook code on a couple of targets, I think 40-bit > integers should also be like that. Floating point types tend not to be defined as bitfields, so naturally there's no support in c_common_type_for_size. This is something that's only useful for integer modes, and I don't think you can avoid this. We could define such a type in each target that supports it, but since I know about at least three machines where this particular feature exists, I think it makes more sense to expose it in target-independent code. I think doing this would also require uglier changes in c_common_type_for_size. 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 palatable. The fact that the libgcc implementations of typical functions can be used with more than one mode depends on the fact that while we don't know the exact size, we have a nice ladder of types where one is twice as big as the next. int40_t falls outside of that. > What is the function of having both PARTIAL_INT_MODE and > FRACTIONAL_INT_MODE? Not having to change all the targets using PARTIAL_INT_MODE immediately to use the better mechanism. Bernd
