GCC Middle and Back End API Reference
|
Go to the source code of this file.
void estimate_numbers_of_iterations | ( | void | ) |
Records estimates on numbers of iterations of loops.
We don't want to issue signed overflow warnings while getting loop iteration estimates.
bool estimated_loop_iterations | ( | struct loop * | , |
double_int * | |||
) |
HOST_WIDE_INT estimated_loop_iterations_int | ( | struct loop * | ) |
bool estimated_stmt_executions | ( | struct loop * | , |
double_int * | |||
) |
HOST_WIDE_INT estimated_stmt_executions_int | ( | struct loop * | ) |
bool finite_loop_p | ( | struct loop * | ) |
void free_numbers_of_iterations_estimates | ( | void | ) |
Frees the information on upper bounds on numbers of iterations of loops.
void free_numbers_of_iterations_estimates_loop | ( | struct loop * | ) |
bool loop_only_exit_p | ( | const struct loop * | , |
const_edge | |||
) |
bool max_loop_iterations | ( | struct loop * | , |
double_int * | |||
) |
HOST_WIDE_INT max_loop_iterations_int | ( | struct loop * | ) |
bool max_stmt_executions | ( | struct loop * | , |
double_int * | |||
) |
HOST_WIDE_INT max_stmt_executions_int | ( | struct loop * | ) |
bool nowrap_type_p | ( | tree | ) |
bool number_of_iterations_exit | ( | struct loop * | loop, |
edge | exit, | ||
struct tree_niter_desc * | niter, | ||
bool | warn, | ||
bool | every_iteration | ||
) |
Stores description of number of iterations of LOOP derived from EXIT (an exit edge of the LOOP) in NITER. Returns true if some useful information could be derived (and fields of NITER has meaning described in comments at struct tree_niter_desc declaration), false otherwise. If WARN is true and -Wunsafe-loop-optimizations was given, warn if the optimizer is going to use potentially unsafe assumptions. When EVERY_ITERATION is true, only tests that are known to be executed every iteration are considered (i.e. only test that alone bounds the loop).
We want the condition for staying inside loop.
We don't want to see undefined signed overflow warnings while computing the number of iterations.
If NITER has simplified into a constant, update MAX.
With -funsafe-loop-optimizations we assume that nothing bad can happen. But if we can prove that there is overflow or some other source of weird behavior, ignore the loop even with -funsafe-loop-optimizations.
We can provide a more specific warning if one of the operator is constant and the other advances by +1 or -1.
References gimple_location(), input_location, integer_all_onesp(), integer_onep(), integer_zerop(), affine_iv_d::step, and warning_at().
Referenced by loop_has_vector_phi_nodes().
bool scev_probably_wraps_p | ( | tree | base, |
tree | step, | ||
gimple | at_stmt, | ||
struct loop * | loop, | ||
bool | use_overflow_semantics | ||
) |
Return false only when the induction variable BASE + STEP * I is known to not overflow: i.e. when the number of iterations is small enough with respect to the step and initial condition in order to keep the evolution confined in TYPEs bounds. Return true when the iv is known to overflow or when the property is not computable. USE_OVERFLOW_SEMANTICS is true if this function should assume that the rules for overflow of the given language apply (e.g., that signed arithmetics in C does not overflow).
FIXME: We really need something like http://gcc.gnu.org/ml/gcc-patches/2005-06/msg02025.html. We used to test for the following situation that frequently appears during address arithmetics: D.1621_13 = (long unsigned intD.4) D.1620_12; D.1622_14 = D.1621_13 * 8; D.1623_15 = (doubleD.29 *) D.1622_14; And derived that the sequence corresponding to D_14 can be proved to not wrap because it is used for computing a memory access; however, this is not really the case -- for example, if D_12 = (unsigned char) [254,+,1], then D_14 has values 2032, 2040, 0, 8, ..., but the code is still legal.
If we can use the fact that signed and pointer arithmetics does not wrap, we are done.
To be able to use estimates on number of iterations of the loop, we must have an upper bound on the absolute value of the step.
Don't issue signed overflow warnings.
Otherwise, compute the number of iterations before we reach the bound of the type, and verify that the loop is exited before this occurs.
At this point we still don't have a proof that the iv does not overflow: give up.