On 25/07/2014 13:20, Roman Gareev wrote:
I have no idea. Is the Gimple basic block of S_3 never set, or is it set and
deleted on the way?
I think, that it is deleted on the way. I've found out, that the
Gimple basic block will be set, if we add the following code to the
generate_isl_schedule:
bb_schedule = isl_map_set_tuple_id (bb_schedule, isl_dim_in,
isl_id_for_pbb (scop, pbb));
Is at this point the pbb of S_3 still valid? Does it point to valid data?
where isl_id_for_pbb is
static isl_id *
isl_id_for_pbb (scop_p s, poly_bb_p pbb)
{
char name[50];
snprintf (name, sizeof (name), "S_%d", pbb_index (pbb));
return isl_id_alloc (s->ctx, name, pbb);
}
This is surprising. You previously said the pbb pointer is still valid,
but only the pointer that within the pbb that points to the gimple bb is
invalid. I don't really see why setting the isl_id again (pointing to
the very same pbb) helps in preserving the data structures in pbb.
What code does S_3 correspond to?
If I'm not mistaken, it is corresponds to:
res_18 = Cross_BB_scalar_dependence.7[0];
phi_out_of_ssa.4[0] = res_18;
I used the following code from
https://gcc.gnu.org/onlinedocs/gccint/Basic-Blocks.html to dump basic
block of the Gimple basic block:
gimple_stmt_iterator si;
for (si = gsi_start_phis (bb); !gsi_end_p (si); gsi_next (&si))
{
gimple phi = gsi_stmt (si);
print_gimple_stmt (dump_file, phi, 0, TDF_SLIM);
}
for (si = gsi_start_bb (bb); !gsi_end_p (si); gsi_next (&si))
{
gimple stmt = gsi_stmt (si);
print_gimple_stmt (dump_file, stmt, 0, TDF_SLIM);
}
Could you please advise me possible functions from
graphite-sese-to-poly.c, which can delete this?
This is a hard guess. I would propose to debug this in gdb. Add a
breakpoint at a location where pbb/isl_id are set, verify that they are
correctly set and add a watchpoint on the pointer that is set to ZERO.
This should make gdb stop exactly at the point where the information is
lost.
Alternatively, you could also try to run this in valgrind.
Cheers,
Tobias
