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