gccint: Consequences of using poly_int

1 
1 10.2 Consequences of using 'poly_int'
1 =====================================
1 
1 The two main consequences of using polynomial sizes and offsets are
1 that:
1 
1    * there is no total ordering between the values at compile time, and
1 
1    * some operations might yield results that cannot be expressed as a
1      'poly_int'.
1 
1  For example, if X is a runtime invariant, we cannot tell at compile
1 time whether:
1 
1      3 + 4X <= 1 + 5X
1 
1  since the condition is false when X <= 1 and true when X >= 2.
1 
1  Similarly, 'poly_int' cannot represent the result of:
1 
1      (3 + 4X) * (1 + 5X)
1 
1  since it cannot (and in practice does not need to) store powers greater
1 than one.  It also cannot represent the result of:
1 
1      (3 + 4X) / (1 + 5X)
1 
1  The following sections describe how we deal with these restrictions.
1 
1  As described earlier, a 'poly_int<1, T>' has no indeterminates and so
1 degenerates to a compile-time constant of type T.  It would be possible
1 in that case to do all normal arithmetic on the T, and to compare the T
1 using the normal C++ operators.  We deliberately prevent
1 target-independent code from doing this, since the compiler needs to
1 support other 'poly_int<N, T>' as well, regardless of the current
1 target's 'NUM_POLY_INT_COEFFS'.
1 
1  However, it would be very artificial to force target-specific code to
1 follow these restrictions if the target has no runtime indeterminates.
1 There is therefore an implicit conversion from 'poly_int<1, T>' to T
1 when compiling target-specific translation units.
1