[PATCH 1/5] Named address spaces: core middle-end support

[Richard Guenther]

On Thu, Aug 20, 2009 at 4:20 PM, Ulrich Weigand<uweigand@de.ibm.com> wrote:
> Hello, this is the first of a set of five patches to merge named address space support according to ISO/IEC TR 18037 into mainline. This patch contains the core of the required middle-end support: - A new type addr_space_t holds address space numbers. This is a small integer, with 0 refering to the generic address space. - Every type (struct tree_type) now carries an address space number. This set from type qualifiers (via set_type_quals), and accessed via TYPE_ADDR_SPACE. - A MEM RTX may now carry an address space number as part of its memory attributes structure. This is accessed via MEM_ADDR_SPACE. During expansion, this is initialized according to the type's address space. - When defining a DECL in a non-generic address space, varasm.c code never treats it as "common"; this means that the back-end can always use the exising TARGET_ASM_SELECT_SECTION and related hooks to place such DECLs into special sections as required for the target. - Address space information is encoded into DWARF-2 debug info using the DW_AT_address_class attribute. - The target may establish different rules for what addresses are legitimate, depending on the address space the address refers to. To enable this, new hooks TARGET_ADDR_SPACE_LEGITIMATE_ADDRESS_P and TARGET_ADDR_SPACE_LEGITIMIZE_ADDRESS are introduced. (For now, there is no address-space version of LEGITIMIZE_RELOAD_ADDRESS; this hook remains used only for addresses in the generic space.) - Accordingly, we introduce address-space aware variants of most middle-end routines operating on memory addresses: memory_address, memory_address_p, offsettable_address_p, strict_memory_address_p, maybe_memory_address_p. Callers are adapted to use the new routines where appropriate. (The old routines are replaced by macros calling the new routine with 0 as address space argument. This allows us to keep code unchanged where it doesn't matter, e.g. in target code for targets that do not support named address spaces, or in code operating on code or stack addresses.) - Some other middle-end code had to be adapted to pass address spaces around. Code in tree-ssa-loop-ivopts.c used to cache information about legitimiate address formats; this cache now has to be per- address-space. In addition, some other middle-end code now has to take address space info into account; e.g. to recognize that two MEM RTXes are not equivalent if they refer to different address spaces, or that the default libcalls only handle the generic address space. - Finally, converting a pointer into a pointer to another address space requires special treatment. To this purpose, the target needs to provide two additional hooks: TARGET_ADDR_SPACE_SUBSET_P specifies whether one address space is subset of another (according to the definition in TR 18037), and TARGET_ADDR_SPACE_CONVERT is called during expansion to convert pointers between overlapping spaces (where one is a subset of the other). - At the tree level, the middle-end uses a CONVERT_EXPR (as opposed to a NOP_EXPR) to represent a pointer conversion between address spaces. Unfortunately, a number of places made the assumption that even a CONVERT_EXPR between pointer types acts basically like an integer conversion and preseves the numerical value.

CONVERT_EXPR and NOP_EXPR are supposed to be merged and
no differences between them should be introduced.

 However, this is not true for address space conversions.

How can a pointer be valid in two address spaces?

Richard.