On Thu, Apr 28, 2005 at 03:43:22PM -0400, Paul Schlie wrote:
> > 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.
Can an optimizer theoretically not change fundamentally the structure of a
memory
reference, so that the attributes will not be valid any more?
For adress spaces, the biggest problem can be, if access operations to different
address spaces are joined:
eg:
if(???)
{
REG_1=...;
REG_1+=4;
do((MEM REG_1));
}
else
{
REG_2=...;
REG_2+=4;
do((MEM REG_2));
}
where REG_1 and REG_2 are pointer to different address spaces.
to:
if(????)
REG_1=...;
else
REG_1=...;
REG_1+=4;
do((MEM REG_1));
to eg. save space.
Even at tree level, such an change could be done by an optimizer,
if he does not take care of the address spaces.
For RTL level, a problem could be, if some information about
eg how the data is packed, would be stored in the memory attributes.
If an optimizer decides, that not the original pointer value is important, but
pointer to an address inside the data would be more useful, then simply
copying the attributes may give a wrong view about the new MEM.
Because of my experiments with GCC, I conclude, that if we want any kind of
attributes (either in tree or RTL), everything, which deal with it, need
to know about all needed side effects, which can be a problem for
backend specific attributes.
Introducing support for named address spaces in GCC would not be a big problem,
it should be no change for non aware backends as frontends. It could be written
in such way, that an bug in this code cause no regression for not address space
using targets.
The big amount of work will be, to verify that no optimizer will introduce
wrong optimizations.
For my patch, I am still not sure, if I even handle all the MEM_AREA correct
in all sitations or if I need to add the MEM_AREA to other expression too.
mfg Martin Kögler
