Re: [PPL-devel] cray_pointers_2.f90
Konrad Trifunovic wrote:
- the error that I get are random! Yes, that is a nightmare. I suppose
it's memory allocation problem (or probably a memory leak). All the errors come from PPL routines. The problem is that sometimes it crashes on 10th invokation of the dependence analyser, sometimes on 200th.
I would be investigating for a possible memory leak inside dependence analyser (I hope not in PPL).
Hi Konrad,
we routinely test PPL with the help of Valgrind, but something may of course escape. Please let us know if you narrow down the problem to something that is likely to be a bug in PPL. All the best,
Roberto
Hi,
I rather think it is fault of our code, not the PPL one.
What i suspect that there are some memory allocation problems, otherwise I cannot understand why the crashes are nondeterministic. We actually do not check for memory allocation faults, so the faults might be silently propagated to other places in the code.
What happens is that I'm calling the creation of polyhedron and deletion of polyhedron for about 1.000.000 times. Since the code is written in C (we use PPL C interface), we do not receive the exceptions that might occur due to failed allocation.
I will first try to do the code that would check if the allocations failed, so at least I can stop the graphite myself, and not wait until it crashes randomly...
Konrad
2009/7/16 Roberto Bagnara bagnara@cs.unipr.it:
Konrad Trifunovic wrote:
- the error that I get are random! Yes, that is a nightmare. I suppose
it's memory allocation problem (or probably a memory leak). All the errors come from PPL routines. The problem is that sometimes it crashes on 10th invokation of the dependence analyser, sometimes on 200th.
I would be investigating for a possible memory leak inside dependence analyser (I hope not in PPL).
Hi Konrad,
we routinely test PPL with the help of Valgrind, but something may of course escape. Please let us know if you narrow down the problem to something that is likely to be a bug in PPL. All the best,
Roberto
-- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagnara@cs.unipr.it
Hi Konrad,
On Thu, Jul 16, 2009 at 08:32, Konrad Trifunovickonrad.trifunovic@gmail.com wrote:
Hi,
I rather think it is fault of our code, not the PPL one.
I also am suspecting the data dependence code to be faulty here.
I have committed a first patch that fixes all the memory leaks in Graphite that are not linked to the data dependence test.
Then, when I enable the dependence test by default in -O2, i.e. with this patch,
diff --git a/gcc/graphite-sese-to-poly.c b/gcc/graphite-sese-to-poly.c index 8c2755a..935cff7 100644 --- a/gcc/graphite-sese-to-poly.c +++ b/gcc/graphite-sese-to-poly.c @@ -1674,7 +1674,7 @@ build_poly_scop (scop_p scop) build_scop_scattering (scop); build_scop_drs (scop);
- if (0) + if (1) graphite_legal_transform (scop);
return true;
I am getting a lot of errors like this: $ valgrind --leak-check=full ~/gcc/graphite/build-spec/gcc/f951 -fcray-pointer -O2 ./cray_pointers_2.f90 [...] ==23974== Invalid read of size 8 ==23974== at 0x5276879: Parma_Polyhedra_Library::Pointset_Powerset<Parma_Polyhedra_Library::C_Polyhedron>::is_empty() const (ppl.hh:71143) ==23974== by 0x526B275: ppl_Pointset_Powerset_C_Polyhedron_is_empty (ppl_c_Pointset_Powerset_C_Polyhedron.cc:208) ==23974== by 0xF1C48F: graphite_legal_transform_dr (graphite-dependences.c:495) ==23974== by 0xF1C678: graphite_legal_transform_bb (graphite-dependences.c:535) ==23974== by 0xF1C796: graphite_legal_transform (graphite-dependences.c:551) ==23974== by 0xF2BA03: build_poly_scop (graphite-sese-to-poly.c:1869) ==23974== by 0xF17942: graphite_transform_loops (graphite.c:267) ==23974== by 0xAA9F12: graphite_transforms (tree-ssa-loop.c:299) ==23974== by 0x899417: execute_one_pass (passes.c:1293) ==23974== by 0x89965E: execute_pass_list (passes.c:1342) ==23974== by 0x89967C: execute_pass_list (passes.c:1343) ==23974== by 0x89967C: execute_pass_list (passes.c:1343) ==23974== Address 0x797c1c8 is 0 bytes inside a block of size 32 free'd ==23974== at 0x4C260AD: operator delete(void*) (vg_replace_malloc.c:342) ==23974== by 0x5272635: ppl_delete_Pointset_Powerset_C_Polyhedron (ppl_c_Pointset_Powerset_C_Polyhedron.cc:58) ==23974== by 0xF1BC04: build_lexicographically_gt_constraint (graphite-dependences.c:352) ==23974== by 0xF1C02F: dependence_polyhedron_1 (graphite-dependences.c:420) ==23974== by 0xF1C2EF: dependence_polyhedron (graphite-dependences.c:458) ==23974== by 0xF1C482: graphite_legal_transform_dr (graphite-dependences.c:493) ==23974== by 0xF1C678: graphite_legal_transform_bb (graphite-dependences.c:535) ==23974== by 0xF1C796: graphite_legal_transform (graphite-dependences.c:551) ==23974== by 0xF2BA03: build_poly_scop (graphite-sese-to-poly.c:1869) ==23974== by 0xF17942: graphite_transform_loops (graphite.c:267) ==23974== by 0xAA9F12: graphite_transforms (tree-ssa-loop.c:299) ==23974== by 0x899417: execute_one_pass (passes.c:1293) ==23974==
Sebastian
Thanks,
tracked down the leak! Indeed it was in dependence analysis code. Though I'm not happy with runtime of the test, but this is due to not-complete-alias analysis. (the dependence test for this fortran code is called 380000 times!).
Konrad
2009/7/16 Sebastian Pop sebpop@gmail.com:
Hi Konrad,
On Thu, Jul 16, 2009 at 08:32, Konrad Trifunovickonrad.trifunovic@gmail.com wrote:
Hi,
I rather think it is fault of our code, not the PPL one.
I also am suspecting the data dependence code to be faulty here.
I have committed a first patch that fixes all the memory leaks in Graphite that are not linked to the data dependence test.
Then, when I enable the dependence test by default in -O2, i.e. with this patch,
diff --git a/gcc/graphite-sese-to-poly.c b/gcc/graphite-sese-to-poly.c index 8c2755a..935cff7 100644 --- a/gcc/graphite-sese-to-poly.c +++ b/gcc/graphite-sese-to-poly.c @@ -1674,7 +1674,7 @@ build_poly_scop (scop_p scop) build_scop_scattering (scop); build_scop_drs (scop);
- if (0)
- if (1)
graphite_legal_transform (scop);
return true;
I am getting a lot of errors like this: $ valgrind --leak-check=full ~/gcc/graphite/build-spec/gcc/f951 -fcray-pointer -O2 ./cray_pointers_2.f90 [...] ==23974== Invalid read of size 8 ==23974== at 0x5276879: Parma_Polyhedra_Library::Pointset_Powerset<Parma_Polyhedra_Library::C_Polyhedron>::is_empty() const (ppl.hh:71143) ==23974== by 0x526B275: ppl_Pointset_Powerset_C_Polyhedron_is_empty (ppl_c_Pointset_Powerset_C_Polyhedron.cc:208) ==23974== by 0xF1C48F: graphite_legal_transform_dr (graphite-dependences.c:495) ==23974== by 0xF1C678: graphite_legal_transform_bb (graphite-dependences.c:535) ==23974== by 0xF1C796: graphite_legal_transform (graphite-dependences.c:551) ==23974== by 0xF2BA03: build_poly_scop (graphite-sese-to-poly.c:1869) ==23974== by 0xF17942: graphite_transform_loops (graphite.c:267) ==23974== by 0xAA9F12: graphite_transforms (tree-ssa-loop.c:299) ==23974== by 0x899417: execute_one_pass (passes.c:1293) ==23974== by 0x89965E: execute_pass_list (passes.c:1342) ==23974== by 0x89967C: execute_pass_list (passes.c:1343) ==23974== by 0x89967C: execute_pass_list (passes.c:1343) ==23974== Address 0x797c1c8 is 0 bytes inside a block of size 32 free'd ==23974== at 0x4C260AD: operator delete(void*) (vg_replace_malloc.c:342) ==23974== by 0x5272635: ppl_delete_Pointset_Powerset_C_Polyhedron (ppl_c_Pointset_Powerset_C_Polyhedron.cc:58) ==23974== by 0xF1BC04: build_lexicographically_gt_constraint (graphite-dependences.c:352) ==23974== by 0xF1C02F: dependence_polyhedron_1 (graphite-dependences.c:420) ==23974== by 0xF1C2EF: dependence_polyhedron (graphite-dependences.c:458) ==23974== by 0xF1C482: graphite_legal_transform_dr (graphite-dependences.c:493) ==23974== by 0xF1C678: graphite_legal_transform_bb (graphite-dependences.c:535) ==23974== by 0xF1C796: graphite_legal_transform (graphite-dependences.c:551) ==23974== by 0xF2BA03: build_poly_scop (graphite-sese-to-poly.c:1869) ==23974== by 0xF17942: graphite_transform_loops (graphite.c:267) ==23974== by 0xAA9F12: graphite_transforms (tree-ssa-loop.c:299) ==23974== by 0x899417: execute_one_pass (passes.c:1293) ==23974==
Sebastian
On Thu, Jul 16, 2009 at 17:15, Konrad Trifunovickonrad.trifunovic@gmail.com wrote:
Thanks,
tracked down the leak! Indeed it was in dependence analysis code
Can you send out a fix for the leak separately from further improvements?
Though I'm not happy with runtime of the test, but this is due to not-complete-alias analysis. (the dependence test for this fortran code is called 380000 times!).
Also, could you please have a look at the failing testcase when you run make -k check RUNTESTFLAGS=graphite.exp You introduced the fail interchange-8.c in the last data deps caching patch.
Thanks, Sebastian
participants (3)
-
Konrad Trifunovic -
Roberto Bagnara -
Sebastian Pop