> From: Martin Koegler <[EMAIL PROTECTED]>
>> 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?
- I don't see how that could be? As I would expect for example:
static const s[] = "abc"; // to declare a READONLY array of char (s.x)
(volatile)x = (volatile char*)(&s[0] + 1); //
(volatile)x = (volatile char*)(&s[0] + 1); // to generate something like:
(set (mem (symb x)) (mem (plus (plus (symb s.x) (const 0)) (const 1))
(set (mem (symb x)) (mem (plus (plus (symb s.x) (const 0)) (const 1))
Which may be "optimized" by folding the constants representing the
memory reference's effective address, thereby potentially being able
to pre-calculate the references effective address:
(set temp-ptr (plus (symbol s.x) 1))
(set (mem (symb x)) (mem temp-ptr)) ; with either original mem ref used,
(set (mem (symb x)) (mem temp-ptr)) ; or new one with attributes copied.
Thereby although the effective address calculation itself may be
"optimized", the fundamental attributes associated with the declared
object must be maintained. Thereby in effect all effective address
optimizations logically occur within the attributed scope of the original
memory references context, i.e.:
(mem (some-arbitrary-effective-address-expression))
->
(mem (some-optimized-effective-address-expression))
> For adress spaces, the biggest problem can be, if access operations to
> different address spaces are joined:
- there's no such thing:
ptr-diff = (mem ptr) +/- (mem ptr)
(mem ptr) = (mem ptr) +/- ptr-diff
That's all that's possible (all other interpretations are erroneous)
> 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.
- which is erroneous unless both reg_1 and reg_2 are pointers to objects
with identical mem ref attributes (which is also why mem attributes should
be maintained correctly and consistently at the tree level throughout all
phases of optimization, as GCC presently has no ability to differentiate
between types of objects referenced through the use of typed pointers).
> 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.
- unfortunately I don't believe there's any option, as GCC is already
suffering from corners being cut by not properly differentiating between
addresses and offsets, which only further confuses things when attempting
to identify the type of object an arbitrary resulting pointer actually
references; however it seems that restricting effective address
optimizations to occur only within the context of their original mem ref
representation is a great start, and will likely quickly shake out any
miss-optimizations that may remain. (as otherwise, GCC simply won't be
able reliably identify the memory attributes associated with an arbitrary
effective address; as may be necessary to also be visible to the back-end)
