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.
