[Bug other/46677] frontends and tree optimizers use *_TYPE_SIZE

["amylaar at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46677

--- Comment #11 from Jorn Wolfgang Rennecke <amylaar at gcc dot gnu.org> 2010-12-11 07:27:53 UTC ---
(In reply to comment #9)
> On Fri, 26 Nov 2010, amylaar at gcc dot gnu.org wrote:

> > 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.
> 
> I'd guess a separate hook; they tend to vary somewhat independently from 
> integer types.  bool would probably also be separate.  So you might have 
> hooks for: general integer types; bool; binary floating-point; decimal 
> floating-point; fixed-point; hook definitions would all have a 
> gcc_unreachable (); default case to catch inappropriate enum values being 
> passed in.  And another hook for ADA_LONG_TYPE_SIZE (defaulting to 
> calling targetm.integer_type_size (itk_long)), I guess.

We don't have any current decimal floating or fixed-point type size macros
to replace.  As discussed elsewhere, the stdint type, wchar type, and ada long
 type sizes are best dealt with by having a hook to define the types in terms
of enum integer_type_kind, and then looking up the size of the type size for
that integer type.

I.e. first, we want to describe the C integer / bool / binary floating
type sizes with three hooks:

DEFHOOK_UNDOC
(integer_type_size,
 "",
 int, (enum integer_type_kind),
 legacy_integer_type_size)

DEFHOOK
(bool_type_size,
 "The size, in bits, of the boolean type used by most front ends that have
such\
  a type.  (Java is an exception, because the language defines the type size.)
\
  The default is @code{CHAR_TYPE_SIZE}.",
 int, (void),
 default_bool_type_size)

DEFHOOK_UNDOC
(float_type_size,
 "",
 int, (enum th_float_type),
 legacy_float_type_size)

We should probably make the type name information corresponding to enum
integer_type_kind / enum th_float_type_size available independent of
the type nodes having been initialized, so that the preprocessor can use the
names without trouble.

In another patch, we can define stdint / wchar / ada long  types
in therms of integer_type_kind.
There'll be slight overlap with the previously mentioned patch in that
we also need to move enum integer_type_kind to coretypes.h . 

We should probably make the type name information corresponding to enum
integer_type_kind / enum th_float_type_size available independent of
the type nodes having been initialized, so that the preprocessor can use the
names without trouble.

DEFHOOK
(stdint_type,
 "Return the @code{enum integer_type_kind} value corresponding to @var{type}. 
If the type does not exist, return itk_none.",
 enum integer_type_kind, (enum th_stdint type),
 default_stdint_type)

DEFHOOK
(size_type,
 "Return the @code{enum integer_type_kind} value corresponding to @var{type}.",
 enum integer_type_kind, (enum th_size_type type),
 default_size_type)

DEFHOOK
(atomic_type,
 "Return the @code{enum integer_type_kind} value corresponding to
@code{sig_atomic_t}.",
 enum integer_type_kind, (void),
 default_atomic_type)

DEFHOOK
(wchar_type,
 "Return the @code{enum integer_type_kind} value corresponding to @var{type}.",
 enum integer_type_kind (enum th_wchar_type type),
 default_wchar_type)

DEFHOOK
(ada_long_type,
 "Return the @code{enum integer_type_kind} value corresponding to the ada
  @code{long} type.  The default is to use the same type as for C.",
 enum integer_type_kind (void),
 default_ada_long_type)

When these two patches are in, we can then make another patch to replace
the macros of the sizes of stdint / wchar / ada long types with using
the above hooks to fist lookup the enum integer_type_kind of the type, and
then its size .

> Yes, you could as a temporary transitional measure, like for other hooks, 
> but certainly I think all definitions of hooks in terms of the old macros 
> should be considered temporary with the aim being to convert all targets 
> and poison the macro names.

Yes, once the above outlined patches to hookize the consumer side are in,
and thus we have defined the interface, we can proceed at will to finish
the process.  Although some definitions seem somewhat tangled, so some or
all of that might have to wait for 4.7, lest we break stuff close to the
release.