Hi,
add_autoinc_candidates begins with this test:
/* If we insert the increment in any position other than the standard
ones, we must ensure that it is incremented once per iteration.
It must not be in an inner nested loop, or one side of an if
statement. */
if (use_bb->loop_father != data->current_loop
|| !dominated_by_p (CDI_DOMINATORS, data->current_loop->latch, use_bb)
|| stmt_could_throw_p (use->stmt)
|| !cst_and_fits_in_hwi (step))
return;
This means that, for languages supporting non-call exceptions like Ada, no
auto-inc candidates will be added for a simple iteration over an array in most
cases since stmt_could_throw_p returns true. I don't think that's necessary,
or else it would also be necessary to test gimple_could_trap_p, which would
have the same effect for all languages. Note that add_autoinc_candidates is
only invoked for USE_ADDRESS use types:
/* At last, add auto-incremental candidates. Make such variables
important since other iv uses with same base object may be based
on it. */
if (use != NULL && use->type == USE_ADDRESS)
add_autoinc_candidates (data, iv->base, iv->step, true, use);
So the attached patch replaces it with stmt_can_throw_internal (which is the
predicate used to compute the flow of control) as e.g. in the vectorizer.
Bootstrapped/regtested on PowerPC64/Linux, OK for the mainline?
2017-10-17 Eric Botcazou <ebotca...@adacore.com>
* tree-ssa-loop-ivopts.c (add_autoinc_candidates): Bail out only if
the use statement can throw internally.
--
Eric Botcazou
Index: tree-ssa-loop-ivopts.c
===================================================================
--- tree-ssa-loop-ivopts.c (revision 253767)
+++ tree-ssa-loop-ivopts.c (working copy)
@@ -3140,7 +3140,7 @@ add_autoinc_candidates (struct ivopts_da
statement. */
if (use_bb->loop_father != data->current_loop
|| !dominated_by_p (CDI_DOMINATORS, data->current_loop->latch, use_bb)
- || stmt_could_throw_p (use->stmt)
+ || stmt_can_throw_internal (use->stmt)
|| !cst_and_fits_in_hwi (step))
return;