After some discussion, how to create transparent access to different memory transparently, I propose the following solution:
We change the GCC core to store the type of each memory expression in the MEM rtx. Backends can use this type information to create a diffent RTL or output a different assembler instruction. The details, how this is done, is the choice of the port. A limitation will be, that some RTL passes change or create memory references and thereby destroy the type attribute. James E Wilson also wrote, that this type information my help for other problems: >For instance, taking the address of packed data and then >dereferencing it fails, because we have no way to mark MEMs as pointing >to packed data. In GCC, a backend could use this in the following way: It defines an attribute (eg. eeprom), which is added to variables and types. The GCC core keeps in all tree based representation already track of such an attribute. Through the type attribute, this information will be available for machine description, which can use this information to generate different instructions. A backend may need multiple of such attributes (avr: progmem and eeprom). For implementing the type attributes, I propose: Add the field "tree type;" to "struct mem_attrs". This field holds the type, if present, or 0, if no type information is available. To access it, I propose: #define MEM_TYPE(RTX) (MEM_ATTRS (RTX) == 0 ? 0 : MEM_ATTRS (RTX)->type) set_mem_attributes_minus_bitpos will set MEM_TYPE, if it is not already set, so the tree to RTL expander adds automatically the type information. All functions, which copy the memory attributes, will also copy the type information. A function set_mem_type to set the type information will be added. Open questions are: *Do we need to print the type information and how verbose in print_rtx? *What to do, if the reload pass copy the REG_EXPR to a MEM_EXPR (set_mem_attrs_from_reg)? If REG_EXPR, copy the type of REG_EXPR, else keep the old type? Or add type information also to REG_ATTRS? Before I start experimenting with this, I want other people opinions, how acceptable this proposal will be for GCC mainline or if it can be improved. A discouraged solution, because it need a change of the interpretation of MEM_EXPR, was: We allow GCC to store in MEM_EXPR not only a DECL or COMPONENT_REF. In the case, something is stored in MEM_EXPR, the type information is present. In any other case, a type will be stored in it (or maybe the full tree expression, which may give additional information to an optimizer). GCC seems to have with this solution no problem, as far as my experiments have shown. An asseration and a missing case in the RTX output need to be changed for my GCC port. mfg Martin Kögler
