This is the mail archive of the
mailing list for the GCC project.
Re: [GSoC] generation of Gimple code from isl_ast_node_if
- From: Tobias Grosser <tobias at grosser dot es>
- To: Roman Gareev <gareevroman at gmail dot com>
- Cc: Mircea Namolaru <mircea dot namolaru at inria dot fr>, gcc-patches at gcc dot gnu dot org
- Date: Fri, 25 Jul 2014 13:30:12 +0200
- Subject: Re: [GSoC] generation of Gimple code from isl_ast_node_if
- Authentication-results: sourceware.org; auth=none
- References: <CABGF_gfK8dqg1WnWODOf0TjmDGpk4_609oKiiBhSq5giE=c-kw at mail dot gmail dot com> <53D0E24B dot 2090101 at grosser dot es> <CABGF_gcOuPFw4ji2H8Rrch_OahjD=d_a16qUR1qkH6H9-xnFRw at mail dot gmail dot com>
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
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)
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;
phi_out_of_ssa.4 = 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:
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
Alternatively, you could also try to run this in valgrind.