On Dec 13, 2013, at 5:11 AM, Richard Biener <rguent...@suse.de> wrote:
> On Fri, 13 Dec 2013, Uros Bizjak wrote:
>
>> 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)
>
> It needs to be a compile-time constant.
>
> Richard.
I will add a line to the effect to the doc before checking it in.
