- Generated by
1.8.1.1
|
GCC Middle and Back End API Reference
|
Data Structures | |
| struct | bounds |
| struct | ilb_data |
|
static |
Add an assumption to NITER that a loop whose ending condition is IV0 < IV1 rolls. TYPE is the type of the control iv. BNDS bounds the value of IV1->base - IV0->base.
We are going to compute the number of iterations as
(iv1->base - iv0->base + step - 1) / step, computed in the unsigned
variant of TYPE. This formula only works if
-step + 1 <= (iv1->base - iv0->base) <= MAX - step + 1
(where MAX is the maximum value of the unsigned variant of TYPE, and
the computations in this formula are performed in full precision,
i.e., without overflows).
Usually, for loops with exit condition iv0->base + step * i < iv1->base,
we have a condition of the form iv0->base - step < iv1->base before the loop,
and for loops iv0->base < iv1->base - step * i the condition
iv0->base < iv1->base + step, due to loop header copying, which enable us
to prove the lower bound.
The upper bound is more complicated. Unless the expressions for initial
and final value themselves contain enough information, we usually cannot
derive it from the context. First check whether the answer does not follow from the bounds we gathered
before. For pointers, only values lying inside a single object
can be compared or manipulated by pointer arithmetics.
Gcc in general does not allow or handle objects larger
than half of the address space, hence the upper bound
is satisfied for pointers. Now the hard part; we must formulate the assumption(s) as expressions, and
we must be careful not to introduce overflow. We need to know that iv0->base >= MIN + iv0->step - 1. Since
0 address never belongs to any object, we can assume this for
pointers. And then we can compute iv0->base - diff, and compare it with
iv1->base.
|
static |
Add assertions to NITER that ensure that the control variable of the loop with ending condition IV0 < IV1 does not overflow. Types of IV0 and IV1 are TYPE. Returns false if we can prove that there is an overflow, true otherwise. STEP is the absolute value of the step.
for (i = iv0->base; i < iv1->base; i += iv0->step)
If iv0->base is a constant, we can determine the last value before
overflow precisely; otherwise we conservatively assume
MAX - STEP + 1. for (i = iv1->base; i > iv0->base; i += iv1->step)
|
static |
Stores the bounds on the value of the expression X - Y in LOOP to BNDS. The subtraction is considered to be performed in arbitrary precision, without overflows. We do not attempt to be too clever regarding the value ranges of X and Y; most of the time, they are just integers or ssa names offsetted by integer. However, we try to use the information contained in the comparisons before the loop (usually created by loop header copying).
Get rid of unnecessary casts, but preserve the value of
the expressions. Special case VARX == VARY -- we just need to compare the
offsets. The matters are a bit more complicated in the
case addition of offsets may wrap. Otherwise, use the value ranges to determine the initial
estimates on below and up. If both X and Y are constants, we cannot get any more precise.
Now walk the dominators of the loop header and use the entry
guards to refine the estimates.
|
static |
Stores the bounds on the difference of the values of the expressions (var + X) and (var + Y), computed in TYPE, to BNDS.
If X == Y, then the expressions are always equal.
If X > Y, there are the following possibilities:
a) neither of var + X and var + Y overflow or underflow, or both of
them do. Then their difference is X - Y.
b) var + X overflows, and var + Y does not. Then the values of the
expressions are var + X - M and var + Y, where M is the range of
the type, and their difference is X - Y - M.
c) var + Y underflows and var + X does not. Their difference again
is M - X + Y.
Therefore, if the arithmetics in type does not overflow, then the
bounds are (X - Y, X - Y), otherwise they are (X - Y - M, X - Y)
Similarly, if X < Y, the bounds are either (X - Y, X - Y) or
(X - Y, X - Y + M).
References bounds::below, and bounds::up.
|
static |
Return index of BOUND in BOUNDS array sorted in increasing order. Lookup by binary search.
Find a matching index by means of a binary search.
References edge_def::dest, and pointer_map_insert().
|
static |
Update the bounds in BNDS that restrict the value of X to the bounds that restrict the value of X + DELTA. X can be obtained as a difference of two values in TYPE.
References bounds::below, and bounds::up.
|
static |
Update the bounds in BNDS that restrict the value of X to the bounds that restrict the value of -X.
|
static |
Returns the loop phi node of LOOP such that ssa name X is derived from its result by a chain of operations such that all but exactly one of their operands are constants.
Referenced by find_loop_niter().
|
static |
Returns a constant upper bound on the value of expression VAL. VAL is considered to be unsigned. If its type is signed, its value must be nonnegative.
|
static |
Returns a constant upper bound on the value of the right-hand side of an assignment statement STMT.
References double_int_to_tree(), integer_nonzerop(), and tree_niter_desc::max.
|
static |
Returns a constant upper bound on the value of expression OP0 CODE OP1, whose type is TYPE. The expression is considered to be unsigned. If its type is signed, its value must be nonnegative.
If TYPE is also signed, the fact that VAL is nonnegative implies
that OP0 is nonnegative. If we cannot prove that the casted expression is nonnegative,
we cannot establish more useful upper bound than the precision
of the type gives us. We now know that op0 is an nonnegative value. Try deriving an upper
bound for it. If the bound does not fit in TYPE, max. value of TYPE could be
attained. Canonicalize to OP0 - CST. Consider CST to be signed, in order to
choose the most logical way how to treat this constant regardless
of the signedness of the type. Avoid CST == 0x80000...
OP0 + CST. We need to check that
BND <= MAX (type) - CST. OP0 - CST, where CST >= 0.
If TYPE is signed, we have already verified that OP0 >= 0, and we
know that the result is nonnegative. This implies that
VAL <= BND - CST.
If TYPE is unsigned, we must additionally know that OP0 >= CST,
otherwise the operation underflows. This should only happen if the type is unsigned; however, for
buggy programs that use overflowing signed arithmetics even with
-fno-wrapv, this condition may also be true for signed values.
Stores estimate on the minimum/maximum value of the expression VAR + OFF in TYPE to MIN and MAX.
If the expression is a constant, we know its value exactly.
If the computation may wrap, we know nothing about the value, except for
the range of the type. Since the addition of OFF does not wrap, if OFF is positive, then we may
add it to MIN, otherwise to MAX.
|
static |
We recorded loop bounds only for statements dominating loop latch (and thus executed each loop iteration). If there are any bounds on statements not dominating the loop latch we can improve the estimate by walking the loop body and seeing if every path from loop header to loop latch contains some bounded statement.
Discover what bounds may interest us.
Exit terminates loop at given iteration, while non-exits produce undefined
effect on the next iteration. If an overflow occurred, ignore the result.
Exit early if there is nothing to do.
Sort the bounds in decreasing order.
For every basic block record the lowest bound that is guaranteed to
terminate the loop. If an overflow occurred, ignore the result.
Perform shortest path discovery loop->header ... loop->latch.
The "distance" is given by the smallest loop bound of basic block
present in the path and we look for path with largest smallest bound
on it.
To avoid the need for fibonacci heap on double ints we simply compress
double ints into indexes to BOUNDS array and then represent the queue
as arrays of queues for every index.
Index of BOUNDS.length() means that the execution of given BB has
no bounds determined.
VISITED is a pointer map translating basic block into smallest index
it was inserted into the priority queue with. Start walk in loop header with index set to infinite bound.
OK, we later inserted the BB with lower priority, skip it.
See if we can improve the bound.
Insert succesors into the queue, watch for latch edge
and record greatest index we saw.
|
static |
Emit a -Waggressive-loop-optimizations warning if needed.
Don't warn if the loop doesn't have known constant bound.
To avoid warning multiple times for the same loop,
only start warning when we preserve loops. Only warn once per loop.
Only warn if undefined behavior gives us lower estimate than the
known constant bound. And undefined behavior happens unconditionally.
|
static |
Compare double ints, callback for qsort.
|
static |
Dumps description of affine induction variable IV to FILE.
References swap_tree_comparison().
| 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.
|
static |
Records estimates on numbers of iterations of LOOP. If USE_UNDEFINED_P is true also use estimates derived from undefined behavior.
Give up if we already have tried to compute an estimation.
Force estimate compuation but leave any existing upper bound in place.
Ensure that loop->nb_iterations is computed if possible. If it turns out
to be constant, we avoid undefined behavior implied bounds and instead
diagnose those loops with -Waggressive-loop-optimizations. If we have a measured profile, use it to estimate the number of
iterations. If we know the exact number of iterations of this loop, try to
not break code with undefined behavior by not recording smaller
maximum number of iterations.
| bool estimated_loop_iterations | ( | ) |
Sets NIT to the estimated number of executions of the latch of the LOOP. If CONSERVATIVE is true, we must be sure that NIT is at least as large as the number of iterations. If we have no reliable estimate, the function returns false, otherwise returns true.
When SCEV information is available, try to update loop iterations
estimate. Otherwise just return whatever we recorded earlier.
References nb_iter_bound::bound.
| HOST_WIDE_INT estimated_loop_iterations_int | ( | ) |
Similar to estimated_loop_iterations, but returns the estimate only if it fits to HOST_WIDE_INT. If this is not the case, or the estimate on the number of iterations of LOOP could not be derived, returns -1.
Referenced by tree_ssa_unswitch_loops().
| bool estimated_stmt_executions | ( | ) |
Sets NIT to the estimated number of executions of the latch of the LOOP, plus one. If we have no reliable estimate, the function returns false, otherwise returns true.
| HOST_WIDE_INT estimated_stmt_executions_int | ( | ) |
Returns an estimate for the number of executions of statements in the LOOP. For statements before the loop exit, this exceeds the number of execution of the latch by one.
If the computation overflows, return -1.
| tree expand_simple_operations | ( | ) |
Expand definitions of ssa names in EXPR as long as they are simple enough, and return the new expression.
Avoid propagating through loop exit phi nodes, which
could break loop-closed SSA form restrictions. Avoid expanding to expressions that contain SSA names that need
to take part in abnormal coalescing. Casts are simple.
And increments and decrements by a constant are simple.
Referenced by alloc_iv().
| tree find_loop_niter | ( | ) |
Try to determine the number of iterations of LOOP. If we succeed, expression giving number of iterations is returned and *EXIT is set to the edge from that the information is obtained. Otherwise chrec_dont_know is returned.
We exit in the first iteration through this exit.
We won't find anything better. Nothing recorded yet.
Prefer constants, the lower the better.
References chain_of_csts_start(), flow_bb_inside_loop_p(), gimple_assign_rhs1(), gimple_assign_rhs_code(), gimple_bb(), gimple_references_memory_p(), loop::header, is_gimple_min_invariant(), and tcc_reference.
| tree find_loop_niter_by_eval | ( | ) |
Finds the exit of the LOOP by that the loop exits after a constant number of iterations and stores the exit edge to *EXIT. The constant giving the number of iterations of LOOP is returned. The number of iterations is determined using loop_niter_by_eval (i.e. by brute force evaluation). If we are unable to find the exit for that loop_niter_by_eval determines the number of iterations, chrec_dont_know is returned.
Loops with multiple exits are expensive to handle and less important.
| bool finite_loop_p | ( | ) |
Return true if loop is known to have bounded number of iterations.
Referenced by analyze_function().
| 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 | ( | ) |
Frees the information on upper bounds on numbers of iterations of LOOP.
|
static |
Determines whether the expression X is derived from a result of a phi node
in header of LOOP such that
* the derivation of X consists only from operations with constants
* the initial value of the phi node is constant
* the value of the phi node in the next iteration can be derived from the
value in the current iteration by a chain of operations with constants.
If such phi node exists, it is returned, otherwise NULL is returned.
|
static |
Given an expression X, then
* if X is NULL_TREE, we return the constant BASE.
* otherwise X is a SSA name, whose value in the considered loop is derived
by a chain of operations with constant from a result of a phi node in
the header of the loop. Then we return value of X when the value of the
result of this phi node is given by the constant BASE. STMT must be either an assignment of a single SSA name or an
expression involving an SSA name and a constant. Try to fold that
expression using the value for the SSA name.
|
static |
For arrays at the end of the structure, we are not guaranteed that they
do not really extend over their declared size. However, for arrays of
size greater than one, this is unlikely to be intended. The case of nonconstant bounds could be handled, but it would be
complicated. The array of length 1 at the end of a structure most likely extends
beyond its bounds. In case the relevant bound of the array does not fit in type, or
it does, but bound + step (in type) still belongs into the range of the
array, the index may wrap and still stay within the range of the array
(consider e.g. if the array is indexed by the full range of
unsigned char).
To make things simpler, we require both bounds to fit into type, although
there are cases where this would not be strictly necessary. If access is not executed on every iteration, we must ensure that overlow may
not make the access valid later.
|
static |
Determine information about number of iterations of a LOOP from the way arrays are used in STMT. RELIABLE is true if STMT is guaranteed to be executed in every iteration of LOOP.
For each memory access, analyze its access function
and record a bound on the loop iteration domain.
|
static |
Determine information about number of iterations of a LOOP from the fact that pointer arithmetics in STMT does not overflow.
In C, pointer arithmetic p + 1 cannot use a NULL pointer, and p - 1 cannot
produce a NULL pointer. The contrary would mean NULL points to an object,
while NULL is supposed to compare unequal with the address of all objects.
Furthermore, p + 1 cannot produce a NULL pointer and p - 1 cannot use a
NULL pointer since that would mean wrapping, which we assume here not to
happen. So, we can exclude NULL from the valid range of pointer
arithmetic.
|
static |
Determine information about number of iterations a LOOP from the bounds of arrays in the data reference REF accessed in STMT. RELIABLE is true if STMT is guaranteed to be executed in every iteration of LOOP.
|
static |
Determine information about number of iterations of a LOOP from the fact that signed arithmetics in STMT does not overflow.
References double_int::is_zero().
|
static |
@verbatim
The following analyzers are extracting informations on the bounds of LOOP from the following undefined behaviors:
If BB is not executed in each iteration of the loop, we cannot
use the operations in it to infer reliable upper bound on the
# of iterations of the loop. However, we can use it as a guess.
Reliable guesses come only from array bounds.
|
static |
Returns inverse of X modulo 2^s, where MASK = 2^s-1.
References build_int_cst(), and int_const_binop().
| tree loop_niter_by_eval | ( | ) |
Tries to count the number of iterations of LOOP till it exits by EXIT by brute force -- i.e. by determining the value of the operands of the condition at EXIT in first few iterations of the loop (assuming that these values are constant) and determining the first one in that the condition is not satisfied. Returns the constant giving the number of the iterations of LOOP if successful, chrec_dont_know otherwise.
Don't issue signed overflow warnings.
References chrec_contains_undetermined(), just_once_each_iteration_p(), edge_def::src, and tree_int_cst_lt().
| bool loop_only_exit_p | ( | ) |
Returns true if EXIT is the only possible exit from LOOP.
Referenced by rewrite_use_compare().
| bool max_loop_iterations | ( | ) |
Sets NIT to an upper bound for the maximum number of executions of the latch of the LOOP. If we have no reliable estimate, the function returns false, otherwise returns true.
When SCEV information is available, try to update loop iterations
estimate. Otherwise just return whatever we recorded earlier.
| HOST_WIDE_INT max_loop_iterations_int | ( | ) |
Similar to max_loop_iterations, but returns the estimate only if it fits to HOST_WIDE_INT. If this is not the case, or the estimate on the number of iterations of LOOP could not be derived, returns -1.
| bool max_stmt_executions | ( | ) |
Sets NIT to the estimated maximum number of executions of the latch of the LOOP, plus one. If we have no reliable estimate, the function returns false, otherwise returns true.
References nb_iter_bound::bound.
Referenced by affine_fn_univar().
|
static |
See if every path cross the loop goes through a statement that is known to not execute at the last iteration. In that case we can decrese iteration count by 1.
Collect all statements with interesting (i.e. lower than
nb_iterations_upper_bound) bound on them.
TODO: Due to the way record_estimate choose estimates to store, the bounds
will be always nb_iterations_upper_bound-1. We can change this to record
also statements not dominating the loop latch and update the walk bellow
to the shortest path algorthm. Start DFS walk in the loop header and see if we can reach the
loop latch or any of the exits (including statements with side
effects that may terminate the loop otherwise) without visiting
any of the statements known to have undefined effect on the last
iteration. Loop for possible exits and statements bounding the execution.
If no bounding statement is found, continue the walk.
If every path through the loop reach bounding statement before exit,
then we know the last iteration of the loop will have undefined effect
and we can decrease number of iterations.
|
static |
Returns true when we can prove that the number of executions of STMT in the loop is at most NITER, according to the bound on the number of executions of the statement NITER_BOUND->stmt recorded in NITER_BOUND and fact that NITER_BOUND->stmt dominate STMT. ??? This code can become quite a CPU hog - we can have many bounds, and large basic block forcing stmt_dominates_stmt_p to be queried many times on a large basic blocks, so the whole thing is O(n^2) for scev_probably_wraps_p invocation (that can be done n times). It would make more sense (and give better answers) to remember BB bounds computed by discover_iteration_bound_by_body_walk.
If the bound does not even fit into NIT_TYPE, it cannot tell us that
the number of iterations is small. We know that NITER_BOUND->stmt is executed at most NITER_BOUND->bound + 1
times. This means that:
-- if NITER_BOUND->is_exit is true, then everything after
it at most NITER_BOUND->bound times.
-- If NITER_BOUND->is_exit is false, then if we can prove that when STMT
is executed, then NITER_BOUND->stmt is executed as well in the same
iteration then STMT is executed at most NITER_BOUND->bound + 1 times.
If we can determine that NITER_BOUND->stmt is always executed
after STMT, then STMT is executed at most NITER_BOUND->bound + 2 times.
We conclude that if both statements belong to the same
basic block and STMT is before NITER_BOUND->stmt and there are no
statements with side effects in between. By stmt_dominates_stmt_p we already know that STMT appears
before NITER_BOUND->STMT. Still need to test that the loop
can not be terinated by a side effect in between.
References nb_iter_bound::bound, loop::bounds, EST_NOT_COMPUTED, loop::estimate_state, ggc_free(), loop::nb_iterations, and nb_iter_bound::next.
| bool nowrap_type_p | ( | ) |
Returns true if the arithmetics in TYPE can be assumed not to wrap.
Referenced by determine_use_iv_cost_address().
|
static |
Determine the number of iterations according to condition (for staying inside loop) which compares two induction variables using comparison operator CODE. The induction variable on left side of the comparison is IV0, the right-hand side is IV1. Both induction variables must have type TYPE, which must be an integer or pointer type. The steps of the ivs must be constants (or NULL_TREE, which is interpreted as constant zero). LOOP is the loop whose number of iterations we are determining. ONLY_EXIT is true if we are sure this is the only way the loop could be exited (including possibly non-returning function calls, exceptions, etc.) -- in this case we can use the information whether the control induction variables can overflow or not in a more efficient way. if EVERY_ITERATION is true, we know the test is executed on every iteration. The results (number of iterations and assumptions as described in comments at struct tree_niter_desc in tree-flow.h) are stored to NITER. Returns false if it fails to determine number of iterations, true if it was determined (possibly with some assumptions).
If the test is not executed every iteration, wrapping may make the test
to pass again.
TODO: the overflow case can be still used as unreliable estimate of upper
bound. But we have no API to pass it down to number of iterations code
and, at present, it will not use it anyway. The meaning of these assumptions is this:
if !assumptions
then the rest of information does not have to be valid
if may_be_zero then the loop does not roll, even if
niter != 0. Make < comparison from > ones, and for NE_EXPR comparisons, ensure that
the control variable is on lhs. Comparison of pointers is undefined unless both iv0 and iv1 point
to the same object. If they do, the control variable cannot wrap
(as wrap around the bounds of memory will never return a pointer
that would be guaranteed to point to the same object, even if we
avoid undefined behavior by casting to size_t and back). If the control induction variable does not overflow and the only exit
from the loop is the one that we analyze, we know it must be taken
eventually. We can handle the case when neither of the sides of the comparison is
invariant, provided that the test is NE_EXPR. This rarely occurs in
practice, but it is simple enough to manage. If the result of the comparison is a constant, the loop is weird. More
precise handling would be possible, but the situation is not common enough
to waste time on it. Ignore loops of while (i-- < 10) type.
If the loop exits immediately, there is nothing to do.
OK, now we know we have a senseful loop. Handle several cases, depending
on what comparison operator is used.
References build_int_cst(), fold_binary_to_constant(), affine_iv_d::no_overflow, affine_iv_d::step, and type().
| 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().
|
static |
Determines number of iterations of loop whose ending condition is IV0 <= IV1. TYPE is the type of the iv. The number of iterations is stored to NITER. EXIT_MUST_BE_TAKEN is true if we know that this condition must eventually become false (we derived this earlier, and possibly set NITER->assumptions to make sure this is the case). BNDS bounds the difference IV1->base - IV0->base.
Say that IV0 is the control variable. Then IV0 <= IV1 iff
IV0 < IV1 + 1, assuming that IV1 is not equal to the greatest
value of the type. This we must know anyway, since if it is
equal to this value, the loop rolls forever. We do not check
this condition for pointer type ivs, as the code cannot rely on
the object to that the pointer points being placed at the end of
the address space (and more pragmatically, TYPE_{MIN,MAX}_VALUE is
not defined for pointers).
|
static |
Determines number of iterations of loop whose ending condition is IV0 < IV1. TYPE is the type of the iv. The number of iterations is stored to NITER. BNDS bounds the difference IV1->base - IV0->base. EXIT_MUST_BE_TAKEN is true if we know that the exit must be taken eventually.
First handle the special case that the step is +-1.
for (i = iv0->base; i < iv1->base; i++)
or
for (i = iv1->base; i > iv0->base; i--).
In both cases # of iterations is iv1->base - iv0->base, assuming that
iv1->base >= iv0->base.
First try to derive a lower bound on the value of
iv1->base - iv0->base, computed in full precision. If the difference
is nonnegative, we are done, otherwise we must record the
condition. If we can determine the final value of the control iv exactly, we can
transform the condition to != comparison. In particular, this will be
the case if DELTA is constant. number_of_iterations_lt_to_ne will add assumptions that ensure that
zps does not overflow. Make sure that the control iv does not overflow.
We determine the number of iterations as (delta + step - 1) / step. For
this to work, we must know that iv1->base >= iv0->base - step + 1,
otherwise the loop does not roll.
|
static |
Checks whether we can determine the final value of the control variable of the loop with ending condition IV0 < IV1 (computed in TYPE). DELTA is the difference IV1->base - IV0->base, STEP is the absolute value of the step. The assumptions necessary to ensure that the computation of the final value does not overflow are recorded in NITER. If we find the final value, we adjust DELTA and return TRUE. Otherwise we return false. BNDS bounds the value of IV1->base - IV0->base, and will be updated by the same amount as DELTA. EXIT_MUST_BE_TAKEN is true if we know that the exit must be taken eventually.
If the induction variable does not overflow and the exit is taken,
then the computation of the final value does not overflow. This is
also obviously the case if the new final value is equal to the
current one. Finally, we postulate this for pointer type variables,
as the code cannot rely on the object to that the pointer points being
placed at the end of the address space (and more pragmatically,
TYPE_{MIN,MAX}_VALUE is not defined for pointers). The final value of the iv is iv1->base + MOD, assuming that this
computation does not overflow, and that
iv0->base <= iv1->base + MOD. The final value of the iv is iv0->base - MOD, assuming that this
computation does not overflow, and that
iv0->base - MOD <= iv1->base.
References affine_iv_d::base, bounds::below, and integer_zerop().
|
static |
Determines number of iterations of loop whose ending condition is IV <> FINAL. TYPE is the type of the iv. The number of iterations is stored to NITER. EXIT_MUST_BE_TAKEN is true if we know that the exit must be taken eventually, i.e., that the IV ever reaches the value FINAL (we derived this earlier, and possibly set NITER->assumptions to make sure this is the case). BNDS contains the bounds on the difference FINAL - IV->base.
Rearrange the terms so that we get inequality S * i <> C, with S
positive. Also cast everything to the unsigned type. If IV does
not overflow, BNDS bounds the value of C. Also, this is the
case if the computation |FINAL - IV->base| does not overflow, i.e.,
if BNDS->below in the result is nonnegative. First the trivial cases -- when the step is 1.
Let nsd (step, size of mode) = d. If d does not divide c, the loop
is infinite. Otherwise, the number of iterations is
(inverse(s/d) * (c/d)) mod (size of mode/d). If we cannot assume that the exit is taken eventually, record the
assumptions for divisibility of c.
|
static |
Derives the upper bound BND on the number of executions of loop with exit
condition S * i <> C. If NO_OVERFLOW is true, then the control variable of
the loop does not overflow. EXIT_MUST_BE_TAKEN is true if we are guaranteed
that the loop ends through this exit, i.e., the induction variable ever
reaches the value of C.
The value C is equal to final - base, where final and base are the final and
initial value of the actual induction variable in the analysed loop. BNDS
bounds the value of this difference when computed in signed type with
unbounded range, while the computation of C is performed in an unsigned
type with the range matching the range of the type of the induction variable.
In particular, BNDS.up contains an upper bound on C in the following cases:
-- if the iv must reach its final value without overflow, i.e., if
NO_OVERFLOW && EXIT_MUST_BE_TAKEN is true, or
-- if final >= base, which we know to hold when BNDS.below >= 0. If C is an exact multiple of S, then its value will be reached before
the induction variable overflows (unless the loop is exited in some
other way before). Note that the actual induction variable in the
loop (which ranges from base to final instead of from 0 to C) may
overflow, in which case BNDS.up will not be giving a correct upper
bound on C; thus, BNDS_U_VALID had to be computed in advance. If the induction variable can overflow, the number of iterations is at
most the period of the control variable (or infinite, but in that case
the whole # of iterations analysis will fail). Now we know that the induction variable does not overflow, so the loop
iterates at most (range of type / S) times. If the induction variable is guaranteed to reach the value of C before
overflow, ... ... then we can strengthen this to C / S, and possibly we can use
the upper bound on C given by BNDS.
References double_int::mask(), mpz_set_double_int(), num_ending_zeros(), and tree_low_cst().
|
static |
Records that AT_STMT is executed at most BOUND + 1 times in LOOP. IS_EXIT is true if the loop is exited immediately after STMT, and this exit is taken at last when the STMT is executed BOUND + 1 times. REALISTIC is true if BOUND is expected to be close to the real number of iterations. UPPER is true if we are sure the loop iterates at most BOUND times. I_BOUND is an unsigned double_int upper estimate on BOUND.
If the I_BOUND is just an estimate of BOUND, it rarely is close to the
real number of iterations. If we have a guaranteed upper bound, record it in the appropriate
list, unless this is an !is_exit bound (i.e. undefined behavior in
at_stmt) in a loop with known constant number of iterations. If statement is executed on every path to the loop latch, we can directly
infer the upper bound on the # of iterations of the loop. Update the number of iteration estimates according to the bound.
If at_stmt is an exit then the loop latch is executed at most BOUND times,
otherwise it can be executed BOUND + 1 times. We will lower the estimate
later if such statement must be executed on last iteration If an overflow occurred, ignore the result.
|
static |
Record the estimate on number of iterations of LOOP based on the fact that the induction variable BASE + STEP * i evaluated in STMT does not wrap and its values belong to the range <LOW, HIGH>. REALISTIC is true if the estimated number of iterations is expected to be close to the real one. UPPER is true if we are sure the induction variable does not wrap.
STMT is executed at most NITER_BOUND + 1 times, since otherwise the value
would get out of the range.
|
static |
From condition C0 CMP C1 derives information regarding the difference of values of VARX + OFFX and VARY + OFFY, computed in TYPE, and stores it to BNDS.
We could derive quite precise information from EQ_EXPR, however, such
a guard is unlikely to appear, so we do not bother with handling
it. NE_EXPR comparisons do not contain much of useful information, except for
special case of comparing with the bounds of the type. Ensure that the condition speaks about an expression in the same type
as X and Y. We are only interested in comparisons of expressions based on VARX and
VARY. TODO -- we might also be able to derive some bounds from
expressions containing just one of the variables. If there is no overflow, the condition implies that
(VARX + OFFX) cmp (VARY + OFFY) + (OFFX - OFFY + OFFC1 - OFFC0).
The overflows and underflows may complicate things a bit; each
overflow decreases the appropriate offset by M, and underflow
increases it by M. The above inequality would not necessarily be
true if
-- VARX + OFFX underflows and VARX + OFFC0 does not, or
VARX + OFFC0 overflows, but VARX + OFFX does not.
This may only happen if OFFX < OFFC0.
-- VARY + OFFY overflows and VARY + OFFC1 does not, or
VARY + OFFC1 underflows and VARY + OFFY does not.
This may only happen if OFFY > OFFC1.
| 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.
|
static |
Substitute NEW for OLD in EXPR and fold the result.
Do not bother to replace constants.
|
static |
Tries to simplify EXPR using the conditions on entry to LOOP. Returns the simplified expression (or EXPR unchanged, if no simplification was possible).
Limit walking the dominators to avoid quadraticness in
the number of BBs times the number of loops in degenerate
cases.
|
static |
Tries to simplify EXPR using the evolutions of the loop invariants in the superloops of LOOP. Returns the simplified expression (or EXPR unchanged, if no simplification was possible).
References tree_niter_desc::assumptions, CDI_DOMINATORS, dominated_by_p(), edge_def::flags, gimple_cond_code(), gimple_cond_lhs(), gimple_cond_rhs(), invert_tree_comparison(), last_stmt(), loop::latch, loop_containing_stmt(), simple_iv(), edge_def::src, and type().
|
static |
Splits expression EXPR to a variable part VAR and constant OFFSET.
Fallthru.
Always sign extend the offset.
| bool stmt_dominates_stmt_p | ( | ) |
Returns true if statement S1 dominates statement S2.
| void substitute_in_loop_info | ( | ) |
Substitute value VAL for ssa name NAME inside expressions held at LOOP.
|
static |
Tries to simplify EXPR using the condition COND. Returns the simplified expression (or EXPR unchanged, if no simplification was possible). Wrapper around tree_simplify_using_condition_1 that ensures that chains of simple operations in definitions of ssa names in COND are expanded, so that things like casts or incrementing the value of the bound before the loop do not cause us to fail.
|
static |
Tries to simplify EXPR using the condition COND. Returns the simplified expression (or EXPR unchanged, if no simplification was possible).
In case COND is equality, we may be able to simplify EXPR by copy/constant
propagation, and vice versa. Fold does not handle this, since it is
considered too expensive. We know that e0 == e1. Check whether we cannot simplify expr
using this fact. If e0 == e1 (EXPR) implies !COND, then EXPR cannot be true.
If e0 == e1 (!EXPR) implies !COND, then EXPR must be true.
Check whether COND ==> EXPR.
Check whether COND ==> not EXPR.
1.8.1.1