http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46677
--- Comment #9 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2010-11-26 23:45:16 UTC --- On Fri, 26 Nov 2010, amylaar at gcc dot gnu.org wrote: > > * All the macros relating to the sizes of various C types in bits should > > be replaced by hooks that are only called to create the associated tree > > nodes; elsewhere they should be replaced by TYPE_PRECISION > > (integer_type_node) etc. > > You are not making this easier for LTO to optimize this back to a constant. These don't need to be optimized back to a constant at all. The C type sizes are essentially a front end matter. Most places in the front ends already use TYPE_PRECISION anyway, e.g. when checking if a type is narrower than int so should be promoted to int. Some front-end things are expensive, e.g. C++ parsing; checks of type precisions aren't. The *only* uses of these macros in the C and C++ front ends are uses of CHAR_TYPE_SIZE in c_common_to_target_charset which is used in a few places in builtins.c (via lang_hooks.to_target_charset) and is not performance-sensitive. Optimizers should be checking the precisions of the particular types they are dealing with and not care about what's "int" or "char" at all. > What about the floating-point types? Or would we rather have an > enum type_kind? Although that might be confused with what we used to > have for varargs before gimple, i.e. a kind of type. I'd guess a separate hook; they tend to vary somewhat independently from integer types. bool would probably also be separate. So you might have hooks for: general integer types; bool; binary floating-point; decimal floating-point; fixed-point; hook definitions would all have a gcc_unreachable (); default case to catch inappropriate enum values being passed in. And another hook for ADA_LONG_TYPE_SIZE (defaulting to calling targetm.integer_type_size (itk_long)), I guess. > > (Many targets might define that hook to integer_type_size_il32 or > > integer_type_size_i32l64 or integer_type_size_i16l32 as default versions > > defined for common cases, rather than having their own function.) > > New targets might do that, but I don't see why we would want to rewrite > every target now; we could define the new hook in terms of the old macros. Yes, you could as a temporary transitional measure, like for other hooks, but certainly I think all definitions of hooks in terms of the old macros should be considered temporary with the aim being to convert all targets and poison the macro names.
