Re: proposal to make SIZE_TYPE more flexible

[Richard Biener <richard dot guenther at gmail dot com>]

DJ Delorie <dj@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;" ?