This is the mail archive of the gcc@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: RFC: Plan for cleaning up the "Addressing Modes" macros


> 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 src dst)

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




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