Hello! > In addition, this target also changes the way that MAX_BITSIZE_MODE_ANY_INT > is calculated. > The value is heavily used on the wide-int branch to allocate buffers that are > used to hold large > integer values. The change in the way it is computed was motivated by the > i386 port, but there > may be other ports that have the same problem. The i386 port defines two very > large integer > modes that are only used as containers for large vectors. They are never used > for large integers. > The new way of computing this allows a port to say (very early) that some of > these integer modes > are never used to hold numbers and so smaller buffers can be used for integer > calculations. Other > ports that play the same game should follow suit.
Index: gcc/config/i386/i386-modes.def =================================================================== --- gcc/config/i386/i386-modes.def (revision 205895) +++ gcc/config/i386/i386-modes.def (working copy) @@ -90,5 +90,10 @@ VECTOR_MODE (INT, QI, 2); /* INT_MODE (OI, 32); INT_MODE (XI, 64); +/* Keep the OI and XI modes from confusing the compiler into thinking + that these modes could actually be used for computation. They are + only holders for vectors during data movement. */ +#define MAX_BITSIZE_MODE_ANY_INT (128) + /* The symbol Pmode stands for one of the above machine modes (usually SImode). The tm.h file specifies which one. It is not a distinct mode. */ __int128 is avaialble only for x86_64 - 64bit targets, so: #define MAX_BITSIZE_MODE_ANY_INT (TARGET_64BIT ? 128 : 64) Uros.