Re: [patch] TARGET_MEM_REF

[Paul Schlie <schlie at comcast dot net>]

>>> Zdenek Dvorak writes:
>>> ivopts make decisions based on what addressing modes are available at
>>> the target machine.  However, the tree optimizers that follow do not
>>> use this knowledge, and may sometimes spoil the decisions.  An example:
>>> ...
>>> This patch introduces TARGET_MEM_REF tree. This is a memory reference
>>> whose address precisely maps to the addressing mode of the target
>>> architecture.  In particular, the multiplication/additions that are
>>> for free are hidden inside the tree, thus they cannot be played with
>>> by optimizations that do not know about the existence of addressing modes.
>>> As a side effect, the address computations that are not expressible
>>> within the addressing mode are exposed to the tree optimizers; which
>>> seems as a nice bonus.
>>> 
>>> The most complex address TARGET_MEM_REF can express is of form (when
>>> translated to rtl)
>>> 
>>> ((plus (plus (mult INDEX STEP) BASE)
>>>        (const (plus (symbol_ref SYMBOL) OFFSET))))
>>> ...
>> 
>> Might it be reasonably possible to enable this to be sensitive to particular
>> target specific attributes which may have been attached to the symbol or
>> references to the symbol? As it would seem increasingly desirable to be able
>> to associate particular declared objects with particular memory spaces in a
>> target specific way. As each memory space that a particular object has been
>> allocated to based on an assigned attribute may require or be limited to a
>> particular set of access methods based on the target machine's instruction
>> set? (As otherwise this may actually work against the ability to efficiently
>> support independent address spaces, by moving the assumption of a single
>> memory space and it's corresponding available access methods further from
>> the back-end?)
>> 
>> Although this may seem exotic, it seems necessary to even support the basic
>> mapping of static const initializer objects into a ROM based program address
>> space without requiring their redundant and wasteful copying into often
>> limited RAM space upon program initialization just to enable their access by
>> the compiled code, which presently assumes by default that all objects are
>> allocated in a single uniform addressable memory space.
> 
> the answer is "I don't know".  It certainly is possible to attach any
> attributes to TARGET_MEM_REFs, but they seem quite tangential to what
> you call for;  you would in the first place need to determine you need
> to put those attributes there, which seems irrelevant to TARGET_MEM_REFs
> since they are created only very late in the compilation process.
> Also, this seems more like a rtl related request.

Sorry, to be clearer: let's assume a target has defined a named attribute,
whereby any declared object, parameter, or cast type specification may be
further explicitly qualified with this named attribute in the source code.

Where the attribute is specified to direct the front/middle-ends to enforce
type equivalent object and parameter assignments and operations, requiring
an explicit cast for dissimilarly qualified objects as necessary; and is
further assumed that all intermediate representations and/or optimizations
will correspondingly preserve and similarly enforce any derived object's
qualified attributed type correctness.

Where then in the back-end; this attribute, which has been preserved for
every reference to any such qualified object, may be used to both determine
the memory space an object is logically/physically placed within, and/or
correspondingly how that object's value may need to be accessed.

So, given the above; might it be reasonably possible to qualify the
(symbol_ref SYMBOL) with a target specific type qualification attribute
attached to the declared object in the source code, so that TARGET_MEM_REF's
may be specified which are sensitive to it; thereby enabling target specific
allocation and/or access semantics to be applied to any such type attributed
objects?

For example, by possibly extending the semantics of (symbol ...) to add an
optionally specified ATTRIBUTE, a TARGET_MEM_REF template be specified as:

(define-TARGET_MEM_REF XXXX

   ((plus (plus (mult INDEX STEP) BASE)
          (const (plus (symbol_ref SYMBOL [ATTRIBUTE]) OFFSET)))))

   (... specialization as required to access SYMBOL with ATTRIBUTE))

Thereby enabling TARGET_MEM_REF's to be specified by the target which may
be utilized deeper in the compilation/optimization process which are
sensitive to the the specialized access semantics or restricted addressing
modes that objects given various target specific attributes may require?