DJ Delorie <d...@redhat.com> wrote: > >> Everything handling __int128 would be updated to work with a >> target-determined set of types instead. >> >> Preferably, the number of such keywords would be arbitrary (so I >suppose >> there would be a single RID_INTN for them) - that seems cleaner than >the >> system for address space keywords with a fixed block from >RID_ADDR_SPACE_0 >> to RID_ADDR_SPACE_15. > >I did a scan through the gcc source tree trying to track down all the >implications of this, and there were a lot of them, and not just the >RID_* stuff. There's also the integer_types[] array (indexed by >itk_*, which is its own mess)
I don't think we need this. It shoul be split into frontend parts and what we consider part of the C ABI of the target. and c_common_reswords[] array, for >example. > >I think it might not be possible to have one RID_* map to multiple >actual keywords, as there are few cases that need to know *which* intN >is used *and* have access to the original string of the token, and >many cases where code assumes a 1:1 relation between RID_*, a type, >and a keyword string. > >IMHO the key design choices come down to: > >* Do we change a few global const arrays to be dynamic arrays? > >* We need to consider that "position in array" is no longer a suitable > sort key for these arrays. itk_* comes to mind here, but RID_* are > abused sometimes too. (note: I've seen this before, where PSImode > isn't included in "find smallest mode" logic, for example, because > it's no in the array in the same place as SImode) > >* Need to dynamically map keywords/bitsizes/tokens to types in all the > cases where we explicitly check for int128. Some of these places > have explicit "check types in the right order" logic hard-coded that > may need to be changed to a data-search logic. > >* The C++ mangler needs to know what to do with these new types. > >I'll attach my notes from the scan for reference... > >---------------------------------------- >Search for in128 ... >Search for c_common_reswords ... >Search for itk_ ... > >--- . --- > >tree-core.h > > enum integer_type_kind is used to map all integer types "in > order" so we need an alternate way to map them. Currently hard-codes > the itk_int128 types. > >tree.h > > defines int128_unsigned_type_node and int128_integer_type_node > > uses itk_int128 and itk_unsigned_int128 - int128_*_type_node > is an [itk_*] array reference. > >builtin-types.def > > defines BT_INT182 but nothing uses it yet. > >gimple.c > > gimple_signed_or_unsigned_type maps types to their signed or > unsigned variant. Two cases: one checks for int128 > explicitly, the other checks for compatibility with int128. > >tree.c > > make_or_reuse_type maps size/signed to a > int128_integer_type_node etc. > > build_common_tree_nodes makes int128_*_type_node if the target > supports TImode. > >tree-streamer.c > > preload_common_nodes() records one node per itk_* > >--- LTO --- > >lto.c > > read_cgraph_and_symbols() reads one node per integer_types[itk_*] > >--- C-FAMILY --- > >c-lex.c > > intepret_integer scans itk_* to find the best (smallest) type > for integers. > > narrowest_unsigned_type assumes integer_types[itk_*] in > bit-size order, and assumes [N*2] is signed/unsigned pairs. > > narrowest_signed_type: same. > >c-cppbuiltin.c > > __SIZEOF_INTn__ for each intN > >c-pretty-print.c > > prints I128 suffix for int128-sized integer literals. > >c-common.c > > int128_* has an entry in c_global_trees[] > > c_common_reswords[] has an entry for __int128 -> RID_INT128 > > c_common_type_for_size maps int:128 to int128_*_type_node > > c_common_type_for_mode: same. > > c_common_signed_or_unsigned_type - checks for int128 types. > same as igmple_signed_or_unsigned_type?() > > c_build_bitfield_integer_type assigns int128_*_type_node for > :128 fields. > > c_common_nodes_and_builtins maps int128_*_type_node to > RID_INT128 and "__int128". Also maps to decl __int128_t > > keyword_begins_type_specifier() checks for RID_INT128 > >--- C --- > >c-tree.h > > adds cts_int128 to c_typespec_keyword[] > >c-parser.c > > c_parse_init() reads c_common_reswords[] which has __int128, > maps one id to each RID_* code. > > c_token_starts_typename() checks for RID_INT128 > > c_token_starts_declspecs() checks for RID_INT128 > > c_parser_declspecs() checks for RID_INT128 > > c_parser_attribute_any_word() checks for RID_INT128 > > c_parser_objc_selector() checks for RID_INT128 > >c-decl.c > > error for "long __int128" etc throughout > > declspecs_add_type() checks for RID_INT128 > > finish_declspecs() checks for cts_int128 > >--- FORTRAN --- > >ico-c-binding.def > > maps int128_t to c_int128_t via get_int_kind_from_width( > >--- C++ --- > >class.c > > layout_class_types uses itk_* to find the best (smallest) > integer type for overlarge bitfields. > >lex.c > > init_reswords() reads c_common_reswords[], which includes __int128 > >rtti.c > > emit_support_tinfos has a dummy list of types fundamentals[] > that hardcodes int128_*_type_node in it. > >decl.c > > checks for __int128 in declspecs to report if it's not supported. > > finish_enum_value_list() uses itk_* to find the right type for enums. > > build_enumerator() also. > >parser.c > > all RID_INTN need to be in > cp_lexer_next_token_is_decl_specifier_keyword() (simple > true/false) > > cp_parser_simple_type_specifier uses __intN as type selector > in a decl. (has token->keyword available, token->u.value is a tree?) > >mangle.c > > 'n', /* itk_int128 */ > 'o', /* itk_unsigned_int128 */ > >typeck.c > > cp_common_type() needs to know about intN compatibility with > other integer types. > >cp-tree.h > > cp_decl_specifier_seq needs a bool for each intN specified. > (else, what about "__int8 __int16 foo;" ?
