> From: Martin Koegler <[EMAIL PROTECTED]>
>> 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.:
>> ...
> 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 persume that machine descriptions which already don't maintain mem
attributes simply don't need them, as they most likely presume every
pointer simply references the same memory space. (hence don't care).
> 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 the original mem ref attributes derived from their originally enclosed
symbol were maintained, any arbitrary type of memory reference would work.
> 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.
- that would seem like a convenient way to to it as opposed to folks having
to remember to do it properly.
> 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
- thanks.
