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




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