------- Additional Comments From dorit at il dot ibm dot com 2005-05-24 11:53
-------
I can reproduce this problem on powerpc-apple-darwin, even without the
options "-maltivec -mabi-altivec" (which means that no simd vectorization takes
place). What happens is that the scalar_evolution_info hash table is corrupted
between vectorization pass and tree_unroll_loops_completely pass. It looks like
this corruption takes place during pass_lower_vector_ssa (which is enabled by -
ftree-vectorize), when executing the todo_flags_finish for this pass.
The scalar_evolution_info htab before pass_lower_vector_ssa looks like this:
==============================
after execute pass:
(classify_chrec {0, +, 1}_1
affine_univariate
)
(classify_chrec
(classify_chrec {1, +, 1}_2
affine_univariate
)
(classify_chrec {0, +, 1}_2
affine_univariate
)
(
-----------------------------------------
3 affine univariate chrecs
0 affine multivariate chrecs
0 degree greater than 2 polynomials
0 chrec_dont_know chrecs
-----------------------------------------
4 total chrecs
1 with undetermined coefficients
-----------------------------------------
21 chrecs in the scev database
55 sets in the scev database
73 gets in the scev database
-----------------------------------------
)
==============================
After pass_lower_vector_ssa the scalar_evolution_info htab looks like this:
==============================
(classify_chrec <<< Unknown tree: >>>
)
(classify_chrec
(classify_chrec <<< Unknown tree: >>>
)
(classify_chrec <<< Unknown tree: >>>
)
(
-----------------------------------------
0 affine univariate chrecs
0 affine multivariate chrecs
0 degree greater than 2 polynomials
0 chrec_dont_know chrecs
-----------------------------------------
4 total chrecs
1 with undetermined coefficients
-----------------------------------------
21 chrecs in the scev database
55 sets in the scev database
73 gets in the scev database
-----------------------------------------
)
==============================
Removing the "TODO_ggc_collect" from the todo_flags_finish of
pass_lower_vector_ssa solves the problem (in tree-complex.c):
==============================
struct tree_opt_pass pass_lower_vector_ssa =
{
"veclower", /* name */
gate_expand_vector_operations, /* gate */
expand_vector_operations, /* execute */
NULL, /* sub */
NULL, /* next */
0, /* static_pass_number */
0, /* tv_id */
PROP_cfg, /* properties_required */
0, /* properties_provided */
0, /* properties_destroyed */
0, /* todo_flags_start */
TODO_dump_func | TODO_update_ssa /* todo_flags_finish */
- | TODO_ggc_collect | TODO_verify_ssa
+ | TODO_verify_ssa
| TODO_verify_stmts | TODO_verify_flow,
0 /* letter */
};
==============================
Paolo, is the above solution ok with you? If so, I'll go ahead and prepare a
patch. Alternatively, if ggc_collect is really required here, then adding a
call to scev_reset() would also solve the problem (again, in tree-complex.c):
==============================
expand_vector_operations (void)
{
block_stmt_iterator bsi;
basic_block bb;
FOR_EACH_BB (bb)
{
for (bsi = bsi_start (bb); !bsi_end_p (bsi); bsi_next (&bsi))
{
expand_vector_operations_1 (&bsi);
update_stmt_if_modified (bsi_stmt (bsi));
}
}
+
+ scev_reset ();
+
}
==============================
--
What |Removed |Added
----------------------------------------------------------------------------
CC| |paolo dot bonzini at lu dot
| |unisi dot ch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21639
