- * @page type representation of types
- *
- * Datastructure to hold type information.
- *
- * This module supplies a datastructure to represent all types
- * known in the compiled program. This includes types specified
- * in the program as well as types defined by the language. In the
- * view of the intermediate representation there is no difference
- * between these types. Finally it specifies some auxiliary types.
- *
- * There exist several kinds of types, arranged by the structure of
- * the type. A type is described by a set of attributes. Some of
- * these attributes are common to all types, others depend on the
- * kind of the type.
- *
- * Types are different from the modes defined in irmode: Types are
- * on the level of the programming language, modes at the level of
- * the target processor.
- *
- * @see tpop.h
- */
-
-#include "typerep.h"
-
-/** Frees all entities associated with a type.
- * Does not free the array entity.
- * Warning: ensure these entities are not referenced anywhere else.
- */
-void free_type_entities(ir_type *tp);
-
-/** Frees the memory used by the type.
- *
- * Removes the type from the type list. Does not free the entities
- * belonging to the type, except for the array element entity. Does
- * not free if tp is "none" or "unknown". Frees entities in value
- * param subtypes of method types!!! Make sure these are not
- * referenced any more. Further make sure there is no pointer type
- * that refers to this type. */
-void free_type(ir_type *tp);
-
-const tp_op *get_type_tpop(const ir_type *tp);
-ident *get_type_tpop_nameid(const ir_type *tp);
-const char *get_type_tpop_name(const ir_type *tp);
-tp_opcode get_type_tpop_code(const ir_type *tp);
-
-ident *get_type_ident(const ir_type *tp);
-void set_type_ident(ir_type *tp, ident* id);
-const char *get_type_name(const ir_type *tp);
-
-/** The visibility of a type.
- *
- * The visibility of a type indicates, whether entities of this type
- * are accessed or allocated in external code.
- *
- * An entity of a type is allocated in external code, if the external
- * code declares a variable of this type, or dynamically allocates
- * an entity of this type. If the external code declares a (compound)
- * type, that contains entities of this type, the visibility also
- * must be external_allocated.
- *
- * The visibility must be higher than that of all entities, if the
- * type is a compound. Here it is questionable, what happens with
- * static entities. If these are accessed external by direct reference,
- * (a static call to a method, that is also in the dispatch table)
- * it should not affect the visibility of the type.
- *
- *
- * @@@ Do we need a visibility for types?
- * I change the layout of types radically when doing type splitting.
- * I need to know, which fields of classes are accessed in the RTS,
- * e.g., [_length. I may not move [_length to the split part.
- * The layout though, is a property of the type.
- *
- * One could also think of changing the mode of a type ...
- *
- * But, we could also output macros to access the fields, e.g.,
- * ACCESS_[_length (X) X->length // conventional
- * ACCESS_[_length (X) X->_split_ref->length // with type splitting
- *
- * For now I implement this function, that returns the visibility
- * based on the visibility of the entities of a compound ...
- *
- * This function returns visibility_external_visible if one or more
- * entities of a compound type have visibility_external_visible.
- * Entities of types are never visibility_external_allocated (right?).
- * Else returns visibility_local.