This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [GSoC] generation of Gimple code from isl_ast_node_if


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]