This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: RFC: Plan for cleaning up the "Addressing Modes" macros
- From: Paul Schlie <schlie at comcast dot net>
- To: Zack Weinberg <zack at codesourcery dot com>
- Cc: <gcc at gcc dot gnu dot org>
- Date: Mon, 28 Feb 2005 12:08:33 -0500
- Subject: 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?