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