http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46677
--- Comment #5 from Jorn Wolfgang Rennecke <amylaar at gcc dot gnu.org> 2010-11-26 22:08:11 UTC --- (In reply to comment #3) > * Modifiable members of targetm are a bad idea and make LTO-based > devirtualization harder (I'd rather targetm was const for single-target > builds), and these values depend on command-line options so function > members are more appropriate. But if these members are only ever assigned a single constant, wouldn't LTO be able to figure this out? > * 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. > - certainly, it should be fine to replace uses of > the macros in the front ends by using TYPE_PRECISION right now. If the > tree optimizers are using these macros, they probably shouldn't be; to my > mind, it's a bug in a tree optimizer if it depends on details such as what > C "int" happens to be, as opposed to e.g. information about how efficient > computations on particular precisions happen to be. (Thus, existing uses > of TYPE_PRECISION (integer_type_node) in tree optimizers would also be > suspicious.) That might well be true, but by the time all such places are fixed up, the hookization project might be forgotten. > * I already said in <http://gcc.gnu.org/ml/gcc/2010-11/msg00340.html> what > I thought hooks for *_TYPE_SIZE should look like; I strongly advise paying > attention to such comments. There might be a case for separating the > standard C integer types from the fixed-point types, say, but I think one > hook for all the standard types is better than separate hooks for each > type. Sorry, that had slipped my mind. 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. > (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.
