An explicit Addressing Mode or mechanism to enable the identification of "read-only" rtl static data references, there by enabling uC, and/or DSP's with Harvard memory architectures, which typically require the use of specialized load instructions to access it's ROM based program memory space, to efficiently access such data without needing to copy it in bulk to the machines typically sparse data memory for use; would be very helpful for such targets.
(as it's not clear how this may be done presently?) > From: Paul Schlie <[EMAIL PROTECTED]> >> Zack Weinberg <zack at codesourcery dot com> >> The target macros described in the "Addressing Modes" section of the >> internals manual are rather badly in need of cleaning up. I see three >> primary reasons why this is so: > > - Very Nice; and wonder, although somewhat orthogonal, if it would be > similarly desirable to clean up GCC's type mode definitions a little, > thereby enabling their declared use by the various targets to be more > consistently conditionally utilized by GCC's built-in data and operator > definitions than they are presently? (for example by unwindxx and libgcc) > > A few other things which would seem possibly nice to be refined include: > > - being able to properly denote/estimate the cost of naked (set dst src) > > - generalizing (set ...) to include an size field, as opposed to > utilizing an odd implied definition for block moves to make it more > consistent with the rest of the operators i.e. (set dst src [size])? > (as an explicit alignment field would seem unnecessary as it could be > implied by the mode of the src and/or destination operands, which > need not be BLK) > > - folding machmode.def and mode-classes.def etc. into machmode.h > (and simply conditionally defining things as may be necessary)? > > - very minor nit, but MODE_RANDOM seems like an odd name for a mode class, > as opposed to MODE_ANY example? >
