This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: different address spaces


On Thu, Apr 28, 2005 at 12:37:48PM -0400, Paul Schlie wrote:
> > Martin Koegler wrote:
> > I have redone the implementation of the eeprom attribute in my prototype.
> > It is now a cleaner solution, but requires larger changes in the core,
> > but the changes in the core should not affect any backend/frontend, if
> > it does not uses them (except a missing case in tree_copy_mem_area, which
> > will cause an assertion to fail).
> > ...
> > +void
> > +tree_copy_mem_area (tree to, tree from)
> > ....
> 
> Alternatively might it make sense to utilize the analogy defined in rtl.h?
> 
>   /* Copy the attributes that apply to memory locations from RHS to LHS.  */
>   #define MEM_COPY_ATTRIBUTES(LHS, RHS)                \
>     (MEM_VOLATILE_P (LHS) = MEM_VOLATILE_P (RHS),            \
>      MEM_IN_STRUCT_P (LHS) = MEM_IN_STRUCT_P (RHS),        \
>      MEM_SCALAR_P (LHS) = MEM_SCALAR_P (RHS),            \
>      MEM_NOTRAP_P (LHS) = MEM_NOTRAP_P (RHS),            \
>      MEM_READONLY_P (LHS) = MEM_READONLY_P (RHS),            \
>      MEM_KEEP_ALIAS_SET_P (LHS) = MEM_KEEP_ALIAS_SET_P (RHS),    \
>      MEM_ATTRS (LHS) = MEM_ATTRS (RHS))
> 
> As unfortunately GCC already inconsistently maintains and copies attributes
> to memory references, it seems that introducing yet another function to do
> so will only likely introduce more inconsistency.
> 
> Therefore wonder if it may be best to simply define MEM_ATTRS as you have
> done, and then consistently utilize MEM_COPY_ATTRIBUTES to properly copy
> attributes associated with memory references when new ones as may need to
> be constructed (as all effective address optimizations should be doing, as
> otherwise the attributes associated with the original reference will be
> lost). I.e.:
> 
> Instead of: (as occasionally incorrectly done)
>  rtx addr1 = copy_to_mode_reg (Pmode, XEXP (operands[1], 0));    // some EA
>  emit_move_insn (tmp_reg_rtx, gen_rtx_MEM (QImode, addr1)); // lose attribs
>  emit_move_insn (addr1, gen_rtx_PLUS (Pmode, addr1, const1_rtx)); // new EA
> 
> Something like this is necessary:
> 
>  rtx addr1 = copy_to_mode_reg (Pmode, XEXP (operands[1], 0));    // some EA
>  rtx mem_1 = gen_rtx_MEM (QImode, addr1);         // gen mem
>  MEM_COPY_ATTRIBUTES (mem_1, operands[1]);        // copy attributes
>  emit_move_insn (tmp_reg_rtx, mem_1);             // read value
>  emit_move_insn (addr1, gen_rtx_PLUS (Pmode, addr1, const1_rtx)); // new EA
>
If you want to use the memory attributes after all reload and optimization
passes, GCC will need to be extended with the missing set of the memory
attributes. This is not my goal (I try to provide the correct
MEM_REF_FLAGS for the RTL expand pass with all necessary earlier steps
to get the adress spaces information).

Correcting all this, will be a lot of work. We may not forget the machine description,
which can also create MEMs.

I have updated my patch.

For the MEM_AREA for the tree, I have eliminated many explicit set operation
of this attribute (build3_COMPONENT_REF and build4_ARRAY_REF completly).

For certain tree codes, the build{1,2,3,4} automatically generate the correct
value of MEM_AREA out of their parameters. Only for INDIRECT_REF, this is
not possible.

If we want get every time the correct attribues, we need to add a source for
the memory attributes to gen_rtx_MEM. For an automtic generation of the
memory attributes, to few information is in the RTL available.

I have added compatibilty checking for memory areas as well as correct handling of
them for ?:.

The new version is at http://www.auto.tuwien.ac.at/~mkoegler/gcc/gcc1.patch

mfg Martin Kögler 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]