This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Unreviewed patch to tree-ssa-loop-ivopts.c
- From: Paul Schlie <schlie at comcast dot net>
- To: Kazu Hirata <kazu at cs dot umass dot edu>
- Cc: <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 04 Apr 2005 03:34:51 -0400
- Subject: Re: Unreviewed patch to tree-ssa-loop-ivopts.c
> Could someone review this patch?
>
> ivopts and unsigned_intSI_type_node
> http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01840.html
>
> Without this patch, c4x port doesn't build (according to the patch
> description).
Unless I misunderstand Richard already objected and was ignored. Although
such a target specific patch should likely never have been proposed in the
first place (much less applied).
http://gcc.gnu.org/ml/gcc-patches/2004-09/msg00580.html
>From a practical point of view, as all targets have adopted the general
convention that Qx/Hx/Sx/Dx/etc. ... modes correspond to 8/16/32/64/etc.
data types (with the exception of c4x which should likely be fixed), it
seems fairly straight forward to formally adopt a basic convention (with
some flexibility to accommodate targets which may choose to support non
typical 8-bit bytes) and simply document it possibly along the line of:
XXXX_TYPE_SIZE
min MODE max (typ) scale
-----------------------------
0 < Bx <= 1 (a typical bit)
1 < Qx <= 12 (typ 8) ~ x1 (a typical byte)
12 < Hx <= 24 (typ 16) ~ x2
24 < Sx <= 48 (typ 32) ~ x4
48 < Dx <= 64 (typ 64) ~ x8
64 < Xx <= 96 (typ 80/96) ~ x10/12
96 < Tx <= 128 (typ 128) ~ x16
Thereby the XXXX_TYPE_SIZE defined by each target is clearly associated
with a corresponding mode and presumed to be scaled proportionately with
respect to each other, just as presently implied but not formally.
Where further to keep things consistent:
BITS_PER_UNIT defines the target's minimum addressable mode size which
should correspond to one of the above modes, and is typically used to
determine packed data alignment requirements, etc.
UNITS_PER_WORD indirectly defines the largest directly addressable type
mode size which should also correspond to one of the above modes but isn't
typically very useful to know, as what's more important is the mode which
corresponds to each of the target's defined type sizes; which may be smaller
or larger than the target's maximum directly addressable type size i.e.:
XXXX_TYPE_SIZE 1 => Bx mode (always)
XXXX_TYPE_SIZE 8 => Qx mode (always)
XXXX_TYPE_SIZE 16 => Hx mode (always)
XXXX_TYPE_SIZE 32 => Sx mode (always)
XXXX_TYPE_SIZE 64 => Dx mode (always)
XXXX_TYPE_SIZE 80/96 => Xx mode (always)
XXXX_TYPE_SIZE 128 => TI mode (always)
(thereby then one can define a macro given any XXXX_TYPE_SIZE to return
the mode which corresponds whenever an explicit symbolic mode is required
in lieu of a specific target's specified type size without having to resort
to guessing or assuming that any particular type corresponds to any
particular mode as it's always truly target dependant; and then simply
use the macro __MODE_FOR_SIZE ( __INT_MODE, XXXX_TYPE_SIZE ) as necessary
to retrofit various otherwise needless assumptions used occasionally in
GCC's sources including the above referenced code).