This is the mail archive of the gcc-patches@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: [patch] TARGET_MEM_REF


> 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 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.

-paul-



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