On Fri, Oct 9, 2015 at 11:09 PM, Tom de Vries <tom_devr...@mentor.com> wrote:
> Hi,
>
> In tree-parloops.c:gather_scalar_reductions, we find the comment:
> ...
>   /* As gimple_uid is used by the vectorizer in between
>      vect_analyze_loop_form and destroy_loop_vec_info, we can set
>      gimple_uid of reduc_phi stmts only now.  */
>   reduction_list->traverse <void *, set_reduc_phi_uids> (NULL);
> ...
>
> However, the usage of gimple_uid seems to extend until the
> free_stmt_vec_info_vec call at the end of parallelize_loops (the pass
> top-level function). During free_stmt_vec_info_vec we test for gimple_uid ==
> 0 in vinfo_for_stmt.
>
> By initializing all the phis in the function with -1 before using them in
> the reduct_phi stmts:
> ...
>    destroy_loop_vec_info (simple_loop_info, true);
>    destroy_loop_vec_info (simple_inner_loop_info, true);
>
>
>
>    /* As gimple_uid is used by the vectorizer in between
>       vect_analyze_loop_form and destroy_loop_vec_info, we can set
>       gimple_uid of reduc_phi stmts only now. */
> +  basic_block bb;
> +  FOR_EACH_BB_FN (bb, cfun)
> +    for (gsi = gsi_start_phis (bb); !gsi_end_p (gsi); gsi_next (&gsi))
> +      gimple_set_uid (gsi_stmt (gsi), (unsigned int)-1);
>  reduction_list->traverse <void *, set_reduc_phi_uids> (NULL);
> ...
> we trigger a sigsegv in vinfo_for_stmt while trying to access
> stmt_vec_info_vec[4294967295 - 1].
>
> This patch fixes that by moving the calls to init_stmt_vec_info_vec and
> free_stmt_vec_info_vec from parallelize_loops and gather_scalar_reductions.
>
> Furthermore, now that the gimple_uids are properly initialized, we can in
> reduction_phi:
> - handle 0 (new phi) and -1 (initialized) values, both meaning the
>   phi's not in the table, and
> - assert that returned entries in fact match the phi argument.
>
> OK for trunk if bootstrap and reg-test passes?

Ok.

Richard.

> Thanks,
> - Tom
>

Reply via email to