This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFA: partially hookize *_TYPE_SIZE

On Tue, 30 Nov 2010, Joern Rennecke wrote:

> OTOH ADA_LONG_TYPE_SIZE is just a way of telling that on some targets,
> Ada's "long" type corresponds to C's "long long", so if we go with
> using integer_type_kind macros/hooks as discussed below, it seems to be
> more natural to replace ADA_LONG_TYPE_SIZE with an ada_long_type hook that
> yeuilds an integer_type_kind value.
> yielding ADA_LONG_TYPE macro first, and then

No, I think returning sizes (as int) is right for these hooks.

> > > Regarding WCHAR_TYPE_SIZE, it appears this is used to define a constant
> > > in  We can use GET_IDENTIFIER to find the type from WCHAR_TYPE
> > > only after all the C types have been initialized, so I don't think that
> > > would be safe in this context.  So i made this into a separate hook, too.
> > 
> > I already said this should not be a hook.  The Fortran front end already
> > has support for decoding strings in the form that appear in macros such as
> > WCHAR_TYPE: get_typenode_from_name.  You could easily make that return an
> > integer_type_kind instead and move it out of the Fortran front end.
> That get_typenode_from_name seems to be a hack to make the best out of a bad
> situation - having information to select one element from a small fixed set
> encoded in string form.

Correct.  But I think reusing that machinery would be better than adding a 
new target hook for something that should logically use the information in 
WCHAR_TYPE rather than its own hook.

> The optimizers could also make use of int_fast*_t .

Sounds like a bad idea to me.  In practice these types reflect an 
arbitrary decision by library maintainers that is then used across all 
target architectures for a given library, and the optimizers should use 
information that actually relates to the architecture rather than the 

> So something like (with GPL and GFDL license):
> (size_type,
> "If @var{diff_type} is false, return the @code{integer_type_kind} value for\
> @code{size_type}; if @var{diff_type} is true, return the\
> @code{integer_type_kind} value for @code{ptrdiff_t}.",
> integer_type_kind, (bool diff_type),
> default_size_type)
> (wchar_type,
> "If @var{int_type} is false, return the @code{integer_type_kind} value for\
> @code{wchar_t}; if @var{int_type} is true, return the
> @code{integer_type_kind}\ value for @code{wint_t}.",
> integer_type_kind, (bool int_type),
> default_wchar_type)

I think it's better just to pass enum tree_index values to these hooks, so 
it's immediately obvious from a call what it means rather than needing to 
know which case is "true" and which is "false".

> /* In target.h:
>   enum stdint_type_purpose
>   {
>     stdint_tp_exact, stdint_tp_least, stdint_tp_fast,
>     stdint_tp_max, stdint_tp_pointer
>   };  */
> (stdint_type,
> "Return the @code{integer_type_kind} value for a stdint.h type. \
> @var{byte_power} is an integer int the range 0..3 so that 8 << @{byte_power}\
> is the number of bits requested for the type. \
> If @var{unsigned_p} is true, an unsigned type is requested, otherwise a\
> signed one. \
> @var{purpose} specifies if the size is to be exact, the smallest fitting\
> size is wanted, the fastest, the largest, or one to hold a void pointer. \
> If @var{purpose} is @code{stdint_tp_max} or @code{stdint_tp_pointer},\
> the caller should specify var@{byte_power} as 0,\
> and the callee should use gcc_assert to verify that it is. \
> If the type does not exist, @code{itk_none} is returned.",
> integer_type_kind,
> (int byte_power, bool unsigned_p, stdint_type_purpose purpose),
> default_stdint_type)

This is massively over-complicated.  It would make sense if the types used 
by libraries actually reflected some logical scheme, but they don't, so 
functions such as glibc_stdint_type (implementing the logic in 
glibc-stdint.h) or newlib_stdint_type (newlib-stdint.h) or 
solaris_stdint_type will most naturally use switch statements handling 
each type separately.  And so simply defining a new enum for all the 
stdint.h types, and passing it to the hook, seems best.

> [integer_type_size hook]
> > I think we should define the hook interface so that only one argument is
> > valid for each present macro.  Thus there should be no possibility for
> > targets to give char and signed char different sizes, for example, because
> > only itk_char should ever be passed for all the character types.
> However, when staying with enum integer_size_kind, that would make it
> impossible to loop over the enum values, as seen in my patch for
> tree-ssa-loop-ivopts.c:add_standard_iv_candidates.

Optimizers should not be looping over these values; the type sizes should 
just be a front-end / ABI matter.  The particular type sizes chosen for 
standard C types should be irrelevant to the optimizers.  The optimizers 
may have a use for asking what sizes are available on a target, or 
available and reasonably efficient.  But so far as this isn't already 
possible by looping over machine modes, any hook for that purpose should 
be clearly separate from the hooks that define the C ABI.  (And in Stage 3 
changing this sort of optimizer logic seems rather risky; hookization 
patches at this stage should be essentially janitorial cleanups that 
clearly do not change semantics, such that if they break anything the 
breakage is expected to be obvious rather than subtle.  So keeping the 
optimizers using target int and filing a bug for that inappropriate use of 
ABI-related types seems better than introducing some new logic.)

Joseph S. Myers

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]