Given that scalar evolution analysis of uncounted loops sets
`loop_vec_info->num_iters' to `chrec_dont_know', we use this as the
criterion for probing whether a loop is uncounted or not.
Consequently, we introduce a new access function on `loop_vec_info' to
conveniently test whether a loop in question is uncounted or not, in
the form of `LOOP_VINFO_NITERS_UNCOUNTED_P(L)'.
Default types:
--------------
While the primary exit condition for loops is no longer tied to some
upper limit in the number of executed iterations, similar limits are
still required for vectorization. One example of this is with prolog
peeling. The prolog will always have an IV exit associated with the
misalignment of data accesses within the loop.
Historically, the assumption held that the data-type that this counter
should have could be derived from the type of the niters limit for the
original loop, so we could get the type from `TREE_TYPE (niters)'.
Moving forward, we provide a backup type to be used for iteration
counters when the maximum number of iterations to be run is unknown.
We take this to be `sizetype', given its role in storing the maximum
size of a theoretically possible object of any type (including array).
Default return values:
----------------------
To avoid having to gate all calls to functions that query a loop's
niters value it is better to "teach" such functions how to handle
uncounted loops and have them return a sensible value that can be
handled upon a function's return.
We therefore prevent functions operating on niters from segfaulting by
adding a default `SCEV_NOT_KNOWN' return value when niters information
absent.