This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
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 ttypes.ads. 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
library.
> So something like (with GPL and GFDL license):
>
> DEFHOOK
> (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)
>
> DEFHOOK
> (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
> }; */
> DEFHOOK
> (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
joseph@codesourcery.com