* [GSoC] Elimination of CLooG library installation dependency
@ 2014-08-06 15:22 Roman Gareev
2014-08-06 15:48 ` Tobias Grosser
2014-08-15 11:13 ` Roman Gareev
0 siblings, 2 replies; 30+ messages in thread
From: Roman Gareev @ 2014-08-06 15:22 UTC (permalink / raw)
To: Tobias Grosser; +Cc: Mircea Namolaru, gcc-patches
[-- Attachment #1: Type: text/plain, Size: 928 bytes --]
Hi Tobias,
I've attached the patch, which should eliminate CLooG library
installation dependency from GCC. The CLooG AST generator is still the
main code generator, but the isl ast generator will be chosen in case
of nonavailability of CLooG library.
However, I've found out a problem. Almost all the functions of the ISL
cannot be used without installed CLooG. (I get errors which contain
“undefined reference to...”). Maybe I missed something. What do you
think about this?
I also have a few questions about gcc. Could you please answer them?
Should Makefile.in be regenerated or manually changed? (I haven't
found out how to regenerate it.)
I've used printf to print “The CLooG code generator cannot be used
+(CLooG is not available). The ISL code generator was chosen.\n”.
Should another function be used for this purpose?
--
Cheers, Roman Gareev.
[-- Attachment #2: patch.txt --]
[-- Type: text/plain, Size: 10602 bytes --]
Index: Makefile.in
===================================================================
--- Makefile.in (revision 213622)
+++ Makefile.in (working copy)
@@ -219,6 +219,7 @@
HOST_LIBS="$(STAGE1_LIBS)"; export HOST_LIBS; \
GMPLIBS="$(HOST_GMPLIBS)"; export GMPLIBS; \
GMPINC="$(HOST_GMPINC)"; export GMPINC; \
+ ISLLIBS="$(HOST_ISLLIBS)"; export ISLLIBS; \
ISLINC="$(HOST_ISLINC)"; export ISLINC; \
CLOOGLIBS="$(HOST_CLOOGLIBS)"; export CLOOGLIBS; \
CLOOGINC="$(HOST_CLOOGINC)"; export CLOOGINC; \
@@ -310,6 +311,7 @@
HOST_GMPINC = @gmpinc@
# Where to find ISL
+HOST_ISLLIBS = @isllibs@
HOST_ISLINC = @islinc@
# Where to find CLOOG
Index: Makefile.tpl
===================================================================
--- Makefile.tpl (revision 213622)
+++ Makefile.tpl (working copy)
@@ -222,6 +222,7 @@
HOST_LIBS="$(STAGE1_LIBS)"; export HOST_LIBS; \
GMPLIBS="$(HOST_GMPLIBS)"; export GMPLIBS; \
GMPINC="$(HOST_GMPINC)"; export GMPINC; \
+ ISLLIBS="$(HOST_ISLLIBS)"; export ISLLIBS; \
ISLINC="$(HOST_ISLINC)"; export ISLINC; \
CLOOGLIBS="$(HOST_CLOOGLIBS)"; export CLOOGLIBS; \
CLOOGINC="$(HOST_CLOOGINC)"; export CLOOGINC; \
@@ -313,6 +314,7 @@
HOST_GMPINC = @gmpinc@
# Where to find ISL
+HOST_ISLLIBS = @isllibs@
HOST_ISLINC = @islinc@
# Where to find CLOOG
Index: gcc/config.in
===================================================================
--- gcc/config.in (revision 213622)
+++ gcc/config.in (working copy)
@@ -1705,6 +1705,10 @@
#undef HAVE_cloog
#endif
+/* Define if isl is in use. */
+#ifndef USED_FOR_TARGET
+#undef HAVE_isl
+#endif
/* Define if F_SETLKW supported by fcntl. */
#ifndef USED_FOR_TARGET
Index: gcc/configure
===================================================================
--- gcc/configure (revision 213622)
+++ gcc/configure (working copy)
@@ -27888,9 +27888,14 @@
+if test "x${ISLLIBS}" != "x" ; then
+$as_echo "#define HAVE_isl 1" >>confdefs.h
+fi
+
+
if test "x${CLOOGLIBS}" != "x" ; then
$as_echo "#define HAVE_cloog 1" >>confdefs.h
Index: gcc/configure.ac
===================================================================
--- gcc/configure.ac (revision 213622)
+++ gcc/configure.ac (working copy)
@@ -5514,6 +5514,9 @@
AC_ARG_VAR(ISLLIBS,[How to link ISL])
AC_ARG_VAR(ISLINC,[How to find ISL include files])
+if test "x${ISLLIBS}" != "x" ; then
+ AC_DEFINE(HAVE_isl, 1, [Define if isl is in use.])
+fi
AC_ARG_VAR(CLOOGLIBS,[How to link CLOOG])
AC_ARG_VAR(CLOOGINC,[How to find CLOOG include files])
Index: gcc/graphite-blocking.c
===================================================================
--- gcc/graphite-blocking.c (revision 213622)
+++ gcc/graphite-blocking.c (working copy)
@@ -23,14 +23,16 @@
#include "config.h"
-#ifdef HAVE_cloog
+#ifdef HAVE_isl
#include <isl/set.h>
#include <isl/map.h>
#include <isl/union_map.h>
#include <isl/constraint.h>
+#ifdef HAVE_cloog
#include <cloog/cloog.h>
#include <cloog/isl/domain.h>
#endif
+#endif
#include "system.h"
#include "coretypes.h"
@@ -49,7 +51,7 @@
#include "tree-data-ref.h"
#include "sese.h"
-#ifdef HAVE_cloog
+#ifdef HAVE_isl
#include "graphite-poly.h"
Index: gcc/graphite-dependences.c
===================================================================
--- gcc/graphite-dependences.c (revision 213622)
+++ gcc/graphite-dependences.c (working copy)
@@ -21,15 +21,17 @@
#include "config.h"
-#ifdef HAVE_cloog
+#ifdef HAVE_isl
#include <isl/set.h>
#include <isl/map.h>
#include <isl/union_map.h>
#include <isl/flow.h>
#include <isl/constraint.h>
+#ifdef HAVE_cloog
#include <cloog/cloog.h>
#include <cloog/isl/domain.h>
#endif
+#endif
#include "system.h"
#include "coretypes.h"
@@ -49,7 +51,7 @@
#include "tree-scalar-evolution.h"
#include "sese.h"
-#ifdef HAVE_cloog
+#ifdef HAVE_isl
#include "graphite-poly.h"
#include "graphite-htab.h"
Index: gcc/graphite-interchange.c
===================================================================
--- gcc/graphite-interchange.c (revision 213622)
+++ gcc/graphite-interchange.c (working copy)
@@ -23,15 +23,17 @@
#include "config.h"
-#ifdef HAVE_cloog
+#ifdef HAVE_isl
#include <isl/aff.h>
#include <isl/set.h>
#include <isl/map.h>
#include <isl/union_map.h>
#include <isl/ilp.h>
+#ifdef HAVE_cloog
#include <cloog/cloog.h>
#include <cloog/isl/domain.h>
#endif
+#endif
#include "system.h"
#include "coretypes.h"
@@ -51,7 +53,7 @@
#include "tree-scalar-evolution.h"
#include "sese.h"
-#ifdef HAVE_cloog
+#ifdef HAVE_isl
#include "graphite-poly.h"
/* XXX isl rewrite following comment */
Index: gcc/graphite-isl-ast-to-gimple.c
===================================================================
--- gcc/graphite-isl-ast-to-gimple.c (revision 213623)
+++ gcc/graphite-isl-ast-to-gimple.c (working copy)
@@ -20,7 +20,7 @@
#include "config.h"
-#ifdef HAVE_cloog
+#ifdef HAVE_isl
#include <isl/set.h>
#include <isl/map.h>
#include <isl/union_map.h>
@@ -55,7 +55,7 @@
#include "tree-into-ssa.h"
#include <map>
-#ifdef HAVE_cloog
+#ifdef HAVE_isl
#include "graphite-poly.h"
#include "graphite-isl-ast-to-gimple.h"
Index: gcc/graphite-optimize-isl.c
===================================================================
--- gcc/graphite-optimize-isl.c (revision 213622)
+++ gcc/graphite-optimize-isl.c (working copy)
@@ -20,7 +20,7 @@
#include "config.h"
-#ifdef HAVE_cloog
+#ifdef HAVE_isl
#include <isl/set.h>
#include <isl/map.h>
#include <isl/union_map.h>
@@ -48,7 +48,7 @@
#include "tree-scalar-evolution.h"
#include "sese.h"
-#ifdef HAVE_cloog
+#ifdef HAVE_isl
#include "graphite-poly.h"
static isl_union_set *
Index: gcc/graphite-poly.c
===================================================================
--- gcc/graphite-poly.c (revision 213622)
+++ gcc/graphite-poly.c (working copy)
@@ -21,16 +21,18 @@
#include "config.h"
-#ifdef HAVE_cloog
+#ifdef HAVE_isl
#include <isl/set.h>
#include <isl/map.h>
#include <isl/union_map.h>
#include <isl/constraint.h>
#include <isl/ilp.h>
#include <isl/aff.h>
+#ifdef HAVE_cloog
#include <cloog/cloog.h>
#include <cloog/isl/domain.h>
#endif
+#endif
#include "system.h"
#include "coretypes.h"
@@ -52,7 +54,7 @@
#include "tree-scalar-evolution.h"
#include "sese.h"
-#ifdef HAVE_cloog
+#ifdef HAVE_isl
#include "graphite-poly.h"
#define OPENSCOP_MAX_STRING 256
Index: gcc/graphite-scop-detection.c
===================================================================
--- gcc/graphite-scop-detection.c (revision 213622)
+++ gcc/graphite-scop-detection.c (working copy)
@@ -21,13 +21,15 @@
#include "config.h"
-#ifdef HAVE_cloog
+#ifdef HAVE_isl
#include <isl/set.h>
#include <isl/map.h>
#include <isl/union_map.h>
+#ifdef HAVE_cloog
#include <cloog/cloog.h>
#include <cloog/isl/domain.h>
#endif
+#endif
#include "system.h"
#include "coretypes.h"
@@ -55,7 +57,7 @@
#include "sese.h"
#include "tree-ssa-propagate.h"
-#ifdef HAVE_cloog
+#ifdef HAVE_isl
#include "graphite-poly.h"
#include "graphite-scop-detection.h"
Index: gcc/graphite-sese-to-poly.c
===================================================================
--- gcc/graphite-sese-to-poly.c (revision 213622)
+++ gcc/graphite-sese-to-poly.c (working copy)
@@ -20,16 +20,18 @@
#include "config.h"
-#ifdef HAVE_cloog
+#ifdef HAVE_isl
#include <isl/set.h>
#include <isl/map.h>
#include <isl/union_map.h>
#include <isl/constraint.h>
#include <isl/aff.h>
+#ifdef HAVE_cloog
#include <cloog/cloog.h>
#include <cloog/cloog.h>
#include <cloog/isl/domain.h>
#endif
+#endif
#include "system.h"
#include "coretypes.h"
@@ -62,7 +64,7 @@
#include "sese.h"
#include "tree-ssa-propagate.h"
-#ifdef HAVE_cloog
+#ifdef HAVE_isl
#include "expr.h"
#include "graphite-poly.h"
#include "graphite-sese-to-poly.h"
Index: gcc/graphite.c
===================================================================
--- gcc/graphite.c (revision 213622)
+++ gcc/graphite.c (working copy)
@@ -34,15 +34,17 @@
#include "config.h"
-#ifdef HAVE_cloog
+#ifdef HAVE_isl
#include <isl/set.h>
#include <isl/map.h>
#include <isl/options.h>
#include <isl/union_map.h>
+#ifdef HAVE_cloog
#include <cloog/cloog.h>
#include <cloog/isl/domain.h>
#include <cloog/isl/cloog.h>
#endif
+#endif
#include "system.h"
#include "coretypes.h"
@@ -68,16 +70,19 @@
#include "tree-pass.h"
#include "tree-cfgcleanup.h"
-#ifdef HAVE_cloog
+#ifdef HAVE_isl
#include "graphite-poly.h"
#include "graphite-scop-detection.h"
-#include "graphite-clast-to-gimple.h"
#include "graphite-isl-ast-to-gimple.h"
#include "graphite-sese-to-poly.h"
#include "graphite-htab.h"
+#ifdef HAVE_cloog
+#include "graphite-clast-to-gimple.h"
+
CloogState *cloog_state;
+#endif
/* Print global statistics to FILE. */
@@ -228,7 +233,9 @@
recompute_all_dominators ();
initialize_original_copy_tables ();
+#ifdef HAVE_cloog
cloog_state = cloog_isl_state_malloc (ctx);
+#endif
if (dump_file && dump_flags)
dump_function_to_file (current_function_decl, dump_file, dump_flags);
@@ -251,7 +258,9 @@
tree_estimate_probability ();
}
+#ifdef HAVE_cloog
cloog_state_free (cloog_state);
+#endif
free_original_copy_tables ();
if (dump_file && dump_flags)
@@ -292,12 +301,23 @@
}
bb_pbb_htab_type bb_pbb_mapping (10);
+
+#ifndef HAVE_cloog
+ if(flag_graphite_code_gen == FGRAPHITE_CODE_GEN_CLOOG)
+ {
+ flag_graphite_code_gen = FGRAPHITE_CODE_GEN_ISL;
+ printf ("The CLooG code generator cannot be used \
+(CLooG is not available). The ISL code generator was chosen.\n");
+ }
+#endif
+
FOR_EACH_VEC_ELT (scops, i, scop)
if (dbg_cnt (graphite_scop))
{
scop->ctx = ctx;
build_poly_scop (scop);
+#ifdef HAVE_cloog
if (POLY_SCOP_P (scop)
&& apply_poly_transforms (scop)
&& (((flag_graphite_code_gen == FGRAPHITE_CODE_GEN_ISL)
@@ -305,6 +325,13 @@
|| ((flag_graphite_code_gen == FGRAPHITE_CODE_GEN_CLOOG)
&& graphite_regenerate_ast_cloog (scop, &bb_pbb_mapping))))
need_cfg_cleanup_p = true;
+#else
+ if (POLY_SCOP_P (scop)
+ && apply_poly_transforms (scop)
+ && graphite_regenerate_ast_isl (scop))
+ need_cfg_cleanup_p = true;
+#endif
+
}
free_scops (scops);
@@ -313,12 +340,12 @@
isl_ctx_free (ctx);
}
-#else /* If Cloog is not available: #ifndef HAVE_cloog. */
+#else /* If ISL is not available: #ifndef HAVE_isl. */
static void
graphite_transform_loops (void)
{
- sorry ("Graphite loop optimizations cannot be used");
+ sorry ("Graphite loop optimizations cannot be used (ISL is not available).");
}
#endif
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: [GSoC] Elimination of CLooG library installation dependency 2014-08-06 15:22 [GSoC] Elimination of CLooG library installation dependency Roman Gareev @ 2014-08-06 15:48 ` Tobias Grosser 2014-08-07 13:18 ` Roman Gareev 2014-08-15 11:13 ` Roman Gareev 1 sibling, 1 reply; 30+ messages in thread From: Tobias Grosser @ 2014-08-06 15:48 UTC (permalink / raw) To: Roman Gareev; +Cc: Mircea Namolaru, gcc-patches On 06/08/2014 17:21, Roman Gareev wrote: > Hi Tobias, > > I've attached the patch, which should eliminate CLooG library > installation dependency from GCC. The CLooG AST generator is still the > main code generator, but the isl ast generator will be chosen in case > of nonavailability of CLooG library. Nice. > However, I've found out a problem. Almost all the functions of the ISL > cannot be used without installed CLooG. (I get errors which contain > “undefined reference to...”). Maybe I missed something. What do you > think about this? This is surprising. What is the exact error message? To which library does gcc link (Check with 'ldd cc1')? I wonder if gcc happens to link against the system CLooG/isl instead of the ones you installed? Also, does objdump -x libisl.so show those missing symbols? > I also have a few questions about gcc. Could you please answer them? > > Should Makefile.in be regenerated or manually changed? (I haven't > found out how to regenerate.) I think it is manually maintained. > I've used printf to print “The CLooG code generator cannot be used > +(CLooG is not available). The ISL code generator was chosen.\n”. > Should another function be used for this purpose? I have no idea. Let's leave it for now. I expect the CLooG code to disappear very soon. Also, regarding this patch. It seems you mix two important changes. 1) The configure/makefile changes that make cloog optional 2) The switch from isl to cloog Best starting with 2), followed by 1). To commit 2), I would like you to run a wider set of tests (e.g., the LLVM test suite). If this passes successful, we should give a headsup on the GCC mailing list and ask other people to try the new isl support. If now bugs have found, we switch. Cheers, Tobias ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [GSoC] Elimination of CLooG library installation dependency 2014-08-06 15:48 ` Tobias Grosser @ 2014-08-07 13:18 ` Roman Gareev 2014-08-07 13:35 ` Tobias Grosser 0 siblings, 1 reply; 30+ messages in thread From: Roman Gareev @ 2014-08-07 13:18 UTC (permalink / raw) To: Tobias Grosser; +Cc: Mircea Namolaru, gcc-patches [-- Attachment #1: Type: text/plain, Size: 4986 bytes --] > To commit 2), I would like you to run a wider set of tests (e.g., the LLVM > test suite). If this passes successful, we should give a headsup on the GCC > mailing list and ask other people to try the new isl support. > If now bugs have found, we switch. I've tested the modified version of Graphite using the LLVM test suite and found out regression only in two test cases: /llvm-test-suite/MultiSource/Benchmarks/ASC_Sequoia/CrystalMk/Crystal_Cholesky.c, /llvm-test suite/MultiSource/Benchmarks/Bullet Compilation of /llvm-test-suite/MultiSource/Benchmarks/ASC_Sequoia/CrystalMk/Crystal_Cholesky.c produces the following error message: /home/roman/llvm-test-suite/MultiSource/Benchmarks/ASC_Sequoia/CrystalMk/Crystal_Cholesky.c /home/roman/llvm-test-suite/MultiSource/Benchmarks/Bullet Crystal_Cholesky.c: In function ‘Crystal_Cholesky’: Crystal_Cholesky.c:16:6: internal compiler error: in operator[], at vec.h:736 void Crystal_Cholesky(int nSlip, ^ 0xf1d080 vec<tree_node*, va_heap, vl_embed>::operator[](unsigned int) /home/roman/sec_trunk/gcc/gcc/vec.h:736 0xf1d080 vec<tree_node*, va_heap, vl_ptr>::operator[](unsigned int) /home/roman/sec_trunk/gcc/gcc/vec.h:1202 0xf1d080 build_iv_mapping /home/roman/sec_trunk/gcc/gcc/graphite-isl-ast-to-gimple.c:608 0xf1d080 translate_isl_ast_node_user /home/roman/sec_trunk/gcc/gcc/graphite-isl-ast-to-gimple.c:644 0xf1d080 translate_isl_ast /home/roman/sec_trunk/gcc/gcc/graphite-isl-ast-to-gimple.c:734 0xf1c7d0 translate_isl_ast_for_loop /home/roman/sec_trunk/gcc/gcc/graphite-isl-ast-to-gimple.c:441 0xf1c7d0 translate_isl_ast_node_for /home/roman/sec_trunk/gcc/gcc/graphite-isl-ast-to-gimple.c:580 0xf1c7d0 translate_isl_ast /home/roman/sec_trunk/gcc/gcc/graphite-isl-ast-to-gimple.c:727 0xf1c3e0 translate_isl_ast_node_block /home/roman/sec_trunk/gcc/gcc/graphite-isl-ast-to-gimple.c:669 0xf1c3e0 translate_isl_ast /home/roman/sec_trunk/gcc/gcc/graphite-isl-ast-to-gimple.c:738 0xf1c3e0 translate_isl_ast_node_block /home/roman/sec_trunk/gcc/gcc/graphite-isl-ast-to-gimple.c:669 0xf1c3e0 translate_isl_ast /home/roman/sec_trunk/gcc/gcc/graphite-isl-ast-to-gimple.c:738 0xf1c3e0 translate_isl_ast_node_block /home/roman/sec_trunk/gcc/gcc/graphite-isl-ast-to-gimple.c:669 0xf1c3e0 translate_isl_ast /home/roman/sec_trunk/gcc/gcc/graphite-isl-ast-to-gimple.c:738 0xf1c3e0 translate_isl_ast_node_block /home/roman/sec_trunk/gcc/gcc/graphite-isl-ast-to-gimple.c:669 0xf1c3e0 translate_isl_ast /home/roman/sec_trunk/gcc/gcc/graphite-isl-ast-to-gimple.c:738 0xf1c3e0 translate_isl_ast_node_block /home/roman/sec_trunk/gcc/gcc/graphite-isl-ast-to-gimple.c:669 0xf1c3e0 translate_isl_ast /home/roman/sec_trunk/gcc/gcc/graphite-isl-ast-to-gimple.c:738 0xf1c7d0 translate_isl_ast_for_loop /home/roman/sec_trunk/gcc/gcc/graphite-isl-ast-to-gimple.c:441 0xf1c7d0 translate_isl_ast_node_for /home/roman/sec_trunk/gcc/gcc/graphite-isl-ast-to-gimple.c:580 It is caused by the wrong index of the iv_map (its value is 12), which is greater than its size (its value is equal to loop->num = 8 plus one). I think that we should use the value of number_of_loops for the size of the iv_map (the attached patch implements this), because it is proven to be robust. What do you think about this? The second error is produced by the executable, which is successfully compiled by /llvm-test-suite/MultiSource/Benchmarks/Bullet: “Segmentation fault (core dumped)”. I've used gdb to print stack trace: Segmentation fault (core dumped) ore was generated by `./bullet.simple'. Program terminated with signal 11, Segmentation fault. #0 upcast (colObj=0x0) at /home/roman/llvm-test-suite/MultiSource/Benchmarks/Bullet/include/BulletDynamics/Dynamics/btRigidBody.h:170 170 if (colObj->getInternalType()==btCollisionObject::CO_RIGID_BODY) (gdb) bt #0 upcast (colObj=0x0) at /home/roman/llvm-test-suite/MultiSource/Benchmarks/Bullet/include/BulletDynamics/Dynamics/btRigidBody.h:170 #1 saveKinematicState (timeStep=<optimized out>, this=<optimized out>) at /home/roman/llvm-test-suite/MultiSource/Benchmarks/Bullet/btDiscreteDynamicsWorld.cpp:113 #2 btDiscreteDynamicsWorld::stepSimulation (this=0x14a6ca0, timeStep=0.0166666675, maxSubSteps=1, fixedTimeStep=0.0166666675) at /home/roman/llvm-test-suite/MultiSource/Benchmarks/Bullet/btDiscreteDynamicsWorld.cpp:333 #3 0x0000000000401ed8 in BenchmarkDemo::clientMoveAndDisplay ( this=0x7fff90475840) at /home/roman/llvm-test-suite/MultiSource/Benchmarks/Bullet/BenchmarkDemo.cpp:232 #4 0x0000000000401bd2 in main (argc=<optimized out>, argv=<optimized out>) at /home/roman/llvm-test-suite/MultiSource/Benchmarks/Bullet/main.cpp:63 The executable is produced by compilation of 317 files. That's why I think that it is be better to temporary postpone the consideration. What do you think about this? -- Cheers, Roman Gareev. [-- Attachment #2: ChangeLog_entry.txt --] [-- Type: text/plain, Size: 236 bytes --] 2014-08-07 Roman Gareev <gareevroman@gmail.com> [gcc/] * graphite-isl-ast-to-gimple.c: (translate_isl_ast_node_user): Use nb_loops instead of loop->num + 1. [gcc/testsuite] * gcc.dg/graphite/isl-ast-gen-user-1.c: New testcase. [-- Attachment #3: patch.txt --] [-- Type: text/plain, Size: 2617 bytes --] Index: gcc/graphite-isl-ast-to-gimple.c =================================================================== --- gcc/graphite-isl-ast-to-gimple.c (revision 213690) +++ gcc/graphite-isl-ast-to-gimple.c (working copy) @@ -632,9 +632,9 @@ gcc_assert (GBB_BB (gbb) != ENTRY_BLOCK_PTR_FOR_FN (cfun) && "The entry block should not even appear within a scop"); - loop_p loop = gbb_loop (gbb); - iv_map.create (loop->num + 1); - iv_map.safe_grow_cleared (loop->num + 1); + int nb_loops = number_of_loops (cfun); + iv_map.create (nb_loops); + iv_map.safe_grow_cleared (nb_loops); build_iv_mapping (iv_map, gbb, user_expr, ip, SCOP_REGION (pbb->scop)); isl_ast_expr_free (user_expr); Index: gcc/testsuite/gcc.dg/graphite/isl-ast-gen-user-1.c =================================================================== --- gcc/testsuite/gcc.dg/graphite/isl-ast-gen-user-1.c (revision 0) +++ gcc/testsuite/gcc.dg/graphite/isl-ast-gen-user-1.c (working copy) @@ -0,0 +1,63 @@ +/* { dg-do compile } */ +/* { dg-options "-O2 -fgraphite-identity -fgraphite-code-generator=isl" } */ + +#include <stdio.h> +#include <stdlib.h> + +static const int MS_XTAL_NSLIP_MAX = 12; + +//-------------- +// test Cholesky solver on matrix +//-------------- +void Crystal_Cholesky(int nSlip, + double a[MS_XTAL_NSLIP_MAX][MS_XTAL_NSLIP_MAX], + double r[MS_XTAL_NSLIP_MAX], + double g[MS_XTAL_NSLIP_MAX]) +{ + int i, j, k; + double fdot; + + + /* transfer rhs to solution vector to preserve rhs */ + for ( i = 0; i < nSlip; i++) g[i] = r[i]; + + /* matrix reduction */ + for ( i = 1; i < nSlip; i++) + a[i][0] = a[i][0] / a[0][0]; + + + for ( i = 1; i < nSlip; i++){ + fdot = 0.0; + for ( k = 0; k < i; k++) + fdot += a[i][k] * a[k][i]; + a[i][i] = a[i][i] - fdot; + for ( j = i+1; j < nSlip; j++){ + fdot = 0.0; + for ( k = 0; k < i; k++) + fdot += a[i][k] * a[k][j]; + a[i][j] = a[i][j] - fdot; + fdot = 0.0; + for ( k = 0; k < i; k++) + fdot += a[j][k] * a[k][i]; + a[j][i] = ( a[j][i] - fdot) / a[i][i]; + } + } + + + /* forward reduction of RHS */ + for ( i = 1; i < nSlip; i++ ){ + for ( k = 0; k < i; k++) + g[i] = g[i] - a[i][k] * g[k]; + } + + /* back substitution */ + g[nSlip-1] = g[nSlip-1] / a[nSlip-1][nSlip-1]; + for ( i = nSlip - 2; i >= 0; i=i-1){ + for ( k = i+1; k < nSlip; k++) + g[i] = g[i] - a[i][k]*g[k]; + g[i] = g[i] / a[i][i]; + } +} + + + ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [GSoC] Elimination of CLooG library installation dependency 2014-08-07 13:18 ` Roman Gareev @ 2014-08-07 13:35 ` Tobias Grosser 2014-08-08 13:11 ` Roman Gareev 0 siblings, 1 reply; 30+ messages in thread From: Tobias Grosser @ 2014-08-07 13:35 UTC (permalink / raw) To: Roman Gareev; +Cc: Mircea Namolaru, gcc-patches On 07/08/2014 15:18, Roman Gareev wrote: >> To commit 2), I would like you to run a wider set of tests (e.g., the LLVM >> test suite). If this passes successful, we should give a headsup on the GCC >> mailing list and ask other people to try the new isl support. >> If now bugs have found, we switch. > > I've tested the modified version of Graphite using the LLVM test suite > and found out regression only in two test cases: > /llvm-test-suite/MultiSource/Benchmarks/ASC_Sequoia/CrystalMk/Crystal_Cholesky.c, > /llvm-test suite/MultiSource/Benchmarks/Bullet Very good news. > Compilation of /llvm-test-suite/MultiSource/Benchmarks/ASC_Sequoia/CrystalMk/Crystal_Cholesky.c > produces the following error message: > > /home/roman/llvm-test-suite/MultiSource/Benchmarks/ASC_Sequoia/CrystalMk/Crystal_Cholesky.c > /home/roman/llvm-test-suite/MultiSource/Benchmarks/Bullet > Crystal_Cholesky.c: In function ‘Crystal_Cholesky’: > Crystal_Cholesky.c:16:6: internal compiler error: in operator[], at vec.h:736 > void Crystal_Cholesky(int nSlip, > ^ > 0xf1d080 vec<tree_node*, va_heap, vl_embed>::operator[](unsigned int) > /home/roman/sec_trunk/gcc/gcc/vec.h:736 > 0xf1d080 vec<tree_node*, va_heap, vl_ptr>::operator[](unsigned int) > /home/roman/sec_trunk/gcc/gcc/vec.h:1202 > 0xf1d080 build_iv_mapping > /home/roman/sec_trunk/gcc/gcc/graphite-isl-ast-to-gimple.c:608 > 0xf1d080 translate_isl_ast_node_user > /home/roman/sec_trunk/gcc/gcc/graphite-isl-ast-to-gimple.c:644 > 0xf1d080 translate_isl_ast > /home/roman/sec_trunk/gcc/gcc/graphite-isl-ast-to-gimple.c:734 > 0xf1c7d0 translate_isl_ast_for_loop > /home/roman/sec_trunk/gcc/gcc/graphite-isl-ast-to-gimple.c:441 > 0xf1c7d0 translate_isl_ast_node_for > /home/roman/sec_trunk/gcc/gcc/graphite-isl-ast-to-gimple.c:580 > 0xf1c7d0 translate_isl_ast > /home/roman/sec_trunk/gcc/gcc/graphite-isl-ast-to-gimple.c:727 > 0xf1c3e0 translate_isl_ast_node_block > /home/roman/sec_trunk/gcc/gcc/graphite-isl-ast-to-gimple.c:669 > 0xf1c3e0 translate_isl_ast > /home/roman/sec_trunk/gcc/gcc/graphite-isl-ast-to-gimple.c:738 > 0xf1c3e0 translate_isl_ast_node_block > /home/roman/sec_trunk/gcc/gcc/graphite-isl-ast-to-gimple.c:669 > 0xf1c3e0 translate_isl_ast > /home/roman/sec_trunk/gcc/gcc/graphite-isl-ast-to-gimple.c:738 > 0xf1c3e0 translate_isl_ast_node_block > /home/roman/sec_trunk/gcc/gcc/graphite-isl-ast-to-gimple.c:669 > 0xf1c3e0 translate_isl_ast > /home/roman/sec_trunk/gcc/gcc/graphite-isl-ast-to-gimple.c:738 > 0xf1c3e0 translate_isl_ast_node_block > /home/roman/sec_trunk/gcc/gcc/graphite-isl-ast-to-gimple.c:669 > 0xf1c3e0 translate_isl_ast > /home/roman/sec_trunk/gcc/gcc/graphite-isl-ast-to-gimple.c:738 > 0xf1c3e0 translate_isl_ast_node_block > /home/roman/sec_trunk/gcc/gcc/graphite-isl-ast-to-gimple.c:669 > 0xf1c3e0 translate_isl_ast > /home/roman/sec_trunk/gcc/gcc/graphite-isl-ast-to-gimple.c:738 > 0xf1c7d0 translate_isl_ast_for_loop > /home/roman/sec_trunk/gcc/gcc/graphite-isl-ast-to-gimple.c:441 > 0xf1c7d0 translate_isl_ast_node_for > /home/roman/sec_trunk/gcc/gcc/graphite-isl-ast-to-gimple.c:580 > > It is caused by the wrong index of the iv_map (its value is 12), which > is greater than its size (its value is equal to loop->num = 8 plus > one). I think that we should use the value of number_of_loops for the > size of the iv_map (the attached patch implements this), because it is > proven to be robust. What do you think about this? I think this is fine. On the other side, I think the test case itself is unnecessarily large. I would assume the majority of the code could be deleted while still triggering the bug. Could you give it a shot. > The second error is produced by the executable, which is successfully > compiled by /llvm-test-suite/MultiSource/Benchmarks/Bullet: > “Segmentation fault (core dumped)”. I've used gdb to print stack > trace: > > Segmentation fault (core dumped) > ore was generated by `./bullet.simple'. > Program terminated with signal 11, Segmentation fault. > #0 upcast (colObj=0x0) > at /home/roman/llvm-test-suite/MultiSource/Benchmarks/Bullet/include/BulletDynamics/Dynamics/btRigidBody.h:170 > 170 if (colObj->getInternalType()==btCollisionObject::CO_RIGID_BODY) > (gdb) bt > #0 upcast (colObj=0x0) > at /home/roman/llvm-test-suite/MultiSource/Benchmarks/Bullet/include/BulletDynamics/Dynamics/btRigidBody.h:170 > #1 saveKinematicState (timeStep=<optimized out>, this=<optimized out>) > at /home/roman/llvm-test-suite/MultiSource/Benchmarks/Bullet/btDiscreteDynamicsWorld.cpp:113 > #2 btDiscreteDynamicsWorld::stepSimulation (this=0x14a6ca0, > timeStep=0.0166666675, maxSubSteps=1, fixedTimeStep=0.0166666675) > at /home/roman/llvm-test-suite/MultiSource/Benchmarks/Bullet/btDiscreteDynamicsWorld.cpp:333 > #3 0x0000000000401ed8 in BenchmarkDemo::clientMoveAndDisplay ( > this=0x7fff90475840) > at /home/roman/llvm-test-suite/MultiSource/Benchmarks/Bullet/BenchmarkDemo.cpp:232 > #4 0x0000000000401bd2 in main (argc=<optimized out>, argv=<optimized out>) > at /home/roman/llvm-test-suite/MultiSource/Benchmarks/Bullet/main.cpp:63 > > The executable is produced by compilation of 317 files. That's why I > think that it is be better to temporary postpone the consideration. > What do you think about this? Is there anything else you still would like to do? Otherwise, I believe fixing the last remaining bugs is of high importance, as we want to enable this code as soon as possible to avoid future bitrot. I understand that reducing this may require some work, but I don't think it is that hard. Specifically, you could first compile the individual *.cpp files to .o files once using once graphite once not. You could then copy the files that are compiled without graphite into a new directory and run a script that does the following in a loop: prev_file = None for file in `ls graphite/*`: link all .o files to executable (gcc compfiles/*.o -o executable) result = run executable (./executable) if (result = OK) echo File 'pref_file' introduced bug break cp graphite/file to ./compfiles/ prev_file = file Cheers, Tobias ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [GSoC] Elimination of CLooG library installation dependency 2014-08-07 13:35 ` Tobias Grosser @ 2014-08-08 13:11 ` Roman Gareev 2014-08-08 13:16 ` Tobias Grosser 0 siblings, 1 reply; 30+ messages in thread From: Roman Gareev @ 2014-08-08 13:11 UTC (permalink / raw) To: Tobias Grosser; +Cc: Mircea Namolaru, gcc-patches [-- Attachment #1: Type: text/plain, Size: 7151 bytes --] > I think this is fine. On the other side, I think the test case itself > is unnecessarily large. I would assume the majority of the code could > be deleted while still triggering the bug. Could you give it a shot. I've attached an improved version of the patch. > Is there anything else you still would like to do? I wanted to make the current code available to be able to fix all new possible bugs before 'pencils down'. If I have free time, I'll try to improve the performance of the generation. >Otherwise, I believe fixing the last remaining bugs is of high importance, as we want to enable > this code as soon as possible to avoid future bitrot. > > I understand that reducing this may require some work, but I don't think it > is that hard. Specifically, you could first compile the individual *.cpp > files to .o files once using once graphite once not. I've found out that btCollisionWorld.cpp, btCollisionDispatcher.cpp and btDiscreteDynamicsWorld.llvm.cpp cause “Segmentation fault”. All of them produce similar ASTs: btCollisionWorld.cpp: CLAST generated by CLooG: if (8*T_45 >= -T_44+9) { for (scat_1=0;scat_1<=T_45-1;scat_1++) { if ((8*scat_1+T_44+18446744073709551615)%18446744073709551616 <= 18446744073709551614) { (scat_1); } } } isl_codegen: [P_45, P_44] -> { S_12[i0] -> [0, i0, 0] : exists (e0 = floor((-1 + P_45)/4294967296), e1 = floor((P_44 + 8i0)/18446744073709551616): i0 >= 0 and 4294967296e0 <= -1 + P_45 and 4294967296e0 >= -4294967296 + P_45 and 4294967296e0 <= -1 + P_45 - i0 and i0 <= 2147483646 and 18446744073709551616e1 >= -18446744073709551615 + P_44 + 8i0 and 18446744073709551616e1 <= -1 + P_44 + 8i0) } [P_45, P_44] -> { : exists (e0 = floor((-1 + P_45)/4294967296): 4294967296e0 <= -1 + P_45 and 4294967296e0 >= -2147483647 + P_45 and P_45 >= -2147483648 and P_45 <= 2147483647 and P_44 >= 0 and P_44 <= 18446744073709551615) } [P_45, P_44] -> { [i0, i1, i2] -> separate[o0] } ISL AST generated by ISL: for (int c1 = 0; c1 < P_45; c1 += 1) if ((P_44 + 8 * c1) % 18446744073709551616 >= 1) S_12(c1); btCollisionDispatcher.cpp: CLAST generated by CLooG: if (8*T_81 >= -T_80+9) { for (scat_1=0;scat_1<=T_81-1;scat_1++) { if ((8*scat_1+T_80+18446744073709551615)%18446744073709551616 <= 18446744073709551614) { (scat_1); } } } isl_codegen: [P_81, P_80] -> { S_22[i0] -> [0, i0, 0] : exists (e0 = floor((-1 + P_81)/4294967296), e1 = floor((P_80 + 8i0)/18446744073709551616): i0 >= 0 and 4294967296e0 <= -1 + P_81 and 4294967296e0 >= -4294967296 + P_81 and 4294967296e0 <= -1 + P_81 - i0 and i0 <= 2147483646 and 18446744073709551616e1 >= -18446744073709551615 + P_80 + 8i0 and 18446744073709551616e1 <= -1 + P_80 + 8i0) } [P_81, P_80] -> { : exists (e0 = floor((-1 + P_81)/4294967296): 4294967296e0 <= -1 + P_81 and 4294967296e0 >= -2147483647 + P_81 and P_81 >= -2147483648 and P_81 <= 2147483647 and P_80 >= 0 and P_80 <= 18446744073709551615) } [P_81, P_80] -> { [i0, i1, i2] -> separate[o0] } ISL AST generated by ISL: for (int c1 = 0; c1 < P_81; c1 += 1) if ((P_80 + 8 * c1) % 18446744073709551616 >= 1) S_22(c1); btDiscreteDynamicsWorld.llvm.cpp: CLAST generated by CLooG: if (8*T_24 >= -T_23+9) { for (scat_1=0;scat_1<=T_24-1;scat_1++) { if ((8*scat_1+T_23+18446744073709551615)%18446744073709551616 <= 18446744073709551614) { (scat_1); } } } isl_codegen: [P_24, P_23] -> { S_13[i0] -> [0, i0, 0] : exists (e0 = floor((-1 + P_24)/4294967296), e1 = floor((P_23 + 8i0)/18446744073709551616): i0 >= 0 and 4294967296e0 <= -1 + P_24 and 4294967296e0 >= -4294967296 + P_24 and 4294967296e0 <= -1 + P_24 - i0 and i0 <= 2147483646 and 18446744073709551616e1 >= -18446744073709551615 + P_23 + 8i0 and 18446744073709551616e1 <= -1 + P_23 + 8i0) } [P_24, P_23] -> { : exists (e0 = floor((-1 + P_24)/4294967296): 4294967296e0 <= -1 + P_24 and 4294967296e0 >= -2147483647 + P_24 and P_24 >= -2147483648 and P_24 <= 2147483647 and P_23 >= 0 and P_23 <= 18446744073709551615) } [P_24, P_23] -> { [i0, i1, i2] -> separate[o0] } ISL AST generated by ISL: for (int c1 = 0; c1 < P_24; c1 += 1) if ((P_23 + 8 * c1) % 18446744073709551616 >= 1) S_13(c1); CLAST generated by CLooG: if (8*T_46 >= -T_45+9) { for (scat_1=0;scat_1<=T_46-1;scat_1++) { if ((8*scat_1+T_45+18446744073709551615)%18446744073709551616 <= 18446744073709551614) { (scat_1); } } } isl_codegen: [P_46, P_45] -> { S_16[i0] -> [0, i0, 0] : exists (e0 = floor((-1 + P_46)/4294967296), e1 = floor((P_45 + 8i0)/18446744073709551616): i0 >= 0 and 4294967296e0 <= -1 + P_46 and 4294967296e0 >= -4294967296 + P_46 and 4294967296e0 <= -1 + P_46 - i0 and i0 <= 2147483646 and 18446744073709551616e1 >= -18446744073709551615 + P_45 + 8i0 and 18446744073709551616e1 <= -1 + P_45 + 8i0) } [P_46, P_45] -> { : exists (e0 = floor((-1 + P_46)/4294967296): 4294967296e0 <= -1 + P_46 and 4294967296e0 >= -2147483647 + P_46 and P_46 >= -2147483648 and P_46 <= 2147483647 and P_45 >= 0 and P_45 <= 18446744073709551615) } [P_46, P_45] -> { [i0, i1, i2] -> separate[o0] } ISL AST generated by ISL: for (int c1 = 0; c1 < P_46; c1 += 1) if ((P_45 + 8 * c1) % 18446744073709551616 >= 1) S_16(c1); CLAST generated by CLooG: if (8*T_18 >= -T_17+9) { for (scat_1=0;scat_1<=T_18-1;scat_1++) { if ((8*scat_1+T_17+18446744073709551615)%18446744073709551616 <= 18446744073709551614) { (scat_1); } } } isl_codegen: [P_18, P_17] -> { S_12[i0] -> [0, i0, 0] : exists (e0 = floor((-1 + P_18)/4294967296), e1 = floor((P_17 + 8i0)/18446744073709551616): i0 >= 0 and 4294967296e0 <= -1 + P_18 and 4294967296e0 >= -4294967296 + P_18 and 4294967296e0 <= -1 + P_18 - i0 and i0 <= 2147483646 and 18446744073709551616e1 >= -18446744073709551615 + P_17 + 8i0 and 18446744073709551616e1 <= -1 + P_17 + 8i0) } [P_18, P_17] -> { : exists (e0 = floor((-1 + P_18)/4294967296): 4294967296e0 <= -1 + P_18 and 4294967296e0 >= -2147483647 + P_18 and P_18 >= -2147483648 and P_18 <= 2147483647 and P_17 >= 0 and P_17 <= 18446744073709551615) } [P_18, P_17] -> { [i0, i1, i2] -> separate[o0] } ISL AST generated by ISL: for (int c1 = 0; c1 < P_18; c1 += 1) if ((P_17 + 8 * c1) % 18446744073709551616 >= 1) S_12(c1); I think that, for example, the following code if (8*T_45 >= -T_44+9) { for (scat_1=0;scat_1<=T_45-1;scat_1++) { if ((8*scat_1+T_44+18446744073709551615)%18446744073709551616 <= 18446744073709551614) { (scat_1); } } } is equivalent to if (8*T_45 >= -T_44+9) { for (scat_1=0;scat_1<=T_45-1;scat_1++) { if ((8*scat_1+T_44)%18446744073709551616 <= -1) { (scat_1); } } } If I'm not mistaken it's not equivalent to for (int c1 = 0; c1 < P_45; c1 += 1) if ((P_44 + 8 * c1) % 18446744073709551616 >= 1) S_12(c1); Maybe the ISL generator generates wrong code. What do you think about this? -- Cheers, Roman Gareev. [-- Attachment #2: ChangeLog_entry.txt --] [-- Type: text/plain, Size: 236 bytes --] 2014-08-07 Roman Gareev <gareevroman@gmail.com> [gcc/] * graphite-isl-ast-to-gimple.c: (translate_isl_ast_node_user): Use nb_loops instead of loop->num + 1. [gcc/testsuite] * gcc.dg/graphite/isl-ast-gen-user-1.c: New testcase. [-- Attachment #3: patch.txt --] [-- Type: text/plain, Size: 1463 bytes --] Index: gcc/graphite-isl-ast-to-gimple.c =================================================================== --- gcc/graphite-isl-ast-to-gimple.c (revision 213690) +++ gcc/graphite-isl-ast-to-gimple.c (working copy) @@ -632,9 +632,9 @@ gcc_assert (GBB_BB (gbb) != ENTRY_BLOCK_PTR_FOR_FN (cfun) && "The entry block should not even appear within a scop"); - loop_p loop = gbb_loop (gbb); - iv_map.create (loop->num + 1); - iv_map.safe_grow_cleared (loop->num + 1); + int nb_loops = number_of_loops (cfun); + iv_map.create (nb_loops); + iv_map.safe_grow_cleared (nb_loops); build_iv_mapping (iv_map, gbb, user_expr, ip, SCOP_REGION (pbb->scop)); isl_ast_expr_free (user_expr); Index: gcc/testsuite/gcc.dg/graphite/isl-ast-gen-user-1.c =================================================================== --- gcc/testsuite/gcc.dg/graphite/isl-ast-gen-user-1.c (revision 0) +++ gcc/testsuite/gcc.dg/graphite/isl-ast-gen-user-1.c (working copy) @@ -0,0 +1,25 @@ +/* { dg-do compile } */ +/* { dg-options "-O2 -fgraphite-identity -fgraphite-code-generator=isl" } */ + +#include <stdio.h> +#include <stdlib.h> + +static const int N = 12; + +void Crystal_Cholesky (int nSlip, int a[N][N]) +{ + int i, j, k, fdot = 0; + + for ( i = 1; i < nSlip; i++) + { + for ( j = i+1; j < nSlip; j++) + { + for ( k = 0; k < i; k++) + fdot += a[i][k] * a[k][j]; + a[i][j] = a[i][j] - fdot; + } + } +} + + + ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [GSoC] Elimination of CLooG library installation dependency 2014-08-08 13:11 ` Roman Gareev @ 2014-08-08 13:16 ` Tobias Grosser 2014-08-09 7:42 ` Roman Gareev 0 siblings, 1 reply; 30+ messages in thread From: Tobias Grosser @ 2014-08-08 13:16 UTC (permalink / raw) To: Roman Gareev; +Cc: Mircea Namolaru, gcc-patches On 08/08/2014 15:11, Roman Gareev wrote: >> I think this is fine. On the other side, I think the test case itself >> >is unnecessarily large. I would assume the majority of the code could >> >be deleted while still triggering the bug. Could you give it a shot. > I've attached an improved version of the patch. LGTM. >> >Is there anything else you still would like to do? > I wanted to make the current code available to be able to fix all new > possible bugs before 'pencils down'. If I have free time, I'll try to > improve the performance of the generation. Good, though before let's try to get the correctness right. >> >Otherwise, I believe fixing the last remaining bugs is of high importance, as we want to enable >> >this code as soon as possible to avoid future bitrot. >> > >> >I understand that reducing this may require some work, but I don't think it >> >is that hard. Specifically, you could first compile the individual *.cpp >> >files to .o files once using once graphite once not. > I've found out that btCollisionWorld.cpp, btCollisionDispatcher.cpp > and btDiscreteDynamicsWorld.llvm.cpp cause “Segmentation fault”. All > of them produce similar ASTs: Is this segmentation fault at compile time or at run-time? I believe it was a segfault at run-time due to a miscompile. > btCollisionWorld.cpp: > > CLAST generated by CLooG: > > if (8*T_45 >= -T_44+9) { > for (scat_1=0;scat_1<=T_45-1;scat_1++) { > if ((8*scat_1+T_44+18446744073709551615)%18446744073709551616 <= > 18446744073709551614) { > (scat_1); > } > } > } > > isl_codegen: > > [P_45, P_44] -> { S_12[i0] -> [0, i0, 0] : exists (e0 = floor((-1 + > P_45)/4294967296), e1 = floor((P_44 + 8i0)/18446744073709551616): i0 >> >= 0 and 4294967296e0 <= -1 + P_45 and 4294967296e0 >= -4294967296 + > P_45 and 4294967296e0 <= -1 + P_45 - i0 and i0 <= 2147483646 and > 18446744073709551616e1 >= -18446744073709551615 + P_44 + 8i0 and > 18446744073709551616e1 <= -1 + P_44 + 8i0) } > > [P_45, P_44] -> { : exists (e0 = floor((-1 + P_45)/4294967296): > 4294967296e0 <= -1 + P_45 and 4294967296e0 >= -2147483647 + P_45 and > P_45 >= -2147483648 and P_45 <= 2147483647 and P_44 >= 0 and P_44 <= > 18446744073709551615) } > > [P_45, P_44] -> { [i0, i1, i2] -> separate[o0] } > > ISL AST generated by ISL: > > for (int c1 = 0; c1 < P_45; c1 += 1) > if ((P_44 + 8 * c1) % 18446744073709551616 >= 1) > S_12(c1); > > btCollisionDispatcher.cpp: > > CLAST generated by CLooG: > > if (8*T_81 >= -T_80+9) { > for (scat_1=0;scat_1<=T_81-1;scat_1++) { > if ((8*scat_1+T_80+18446744073709551615)%18446744073709551616 <= > 18446744073709551614) { > (scat_1); > } > } > } > > isl_codegen: > > [P_81, P_80] -> { S_22[i0] -> [0, i0, 0] : exists (e0 = floor((-1 + > P_81)/4294967296), e1 = floor((P_80 + 8i0)/18446744073709551616): i0 >> >= 0 and 4294967296e0 <= -1 + P_81 and 4294967296e0 >= -4294967296 + > P_81 and 4294967296e0 <= -1 + P_81 - i0 and i0 <= 2147483646 and > 18446744073709551616e1 >= -18446744073709551615 + P_80 + 8i0 and > 18446744073709551616e1 <= -1 + P_80 + 8i0) } > > [P_81, P_80] -> { : exists (e0 = floor((-1 + P_81)/4294967296): > 4294967296e0 <= -1 + P_81 and 4294967296e0 >= -2147483647 + P_81 and > P_81 >= -2147483648 and P_81 <= 2147483647 and P_80 >= 0 and P_80 <= > 18446744073709551615) } > > [P_81, P_80] -> { [i0, i1, i2] -> separate[o0] } > > ISL AST generated by ISL: > > for (int c1 = 0; c1 < P_81; c1 += 1) > if ((P_80 + 8 * c1) % 18446744073709551616 >= 1) > S_22(c1); > > btDiscreteDynamicsWorld.llvm.cpp: > > CLAST generated by CLooG: > > if (8*T_24 >= -T_23+9) { > for (scat_1=0;scat_1<=T_24-1;scat_1++) { > if ((8*scat_1+T_23+18446744073709551615)%18446744073709551616 <= > 18446744073709551614) { > (scat_1); > } > } > } > > isl_codegen: > > [P_24, P_23] -> { S_13[i0] -> [0, i0, 0] : exists (e0 = floor((-1 + > P_24)/4294967296), e1 = floor((P_23 + 8i0)/18446744073709551616): i0 >> >= 0 and 4294967296e0 <= -1 + P_24 and 4294967296e0 >= -4294967296 + > P_24 and 4294967296e0 <= -1 + P_24 - i0 and i0 <= 2147483646 and > 18446744073709551616e1 >= -18446744073709551615 + P_23 + 8i0 and > 18446744073709551616e1 <= -1 + P_23 + 8i0) } > > [P_24, P_23] -> { : exists (e0 = floor((-1 + P_24)/4294967296): > 4294967296e0 <= -1 + P_24 and 4294967296e0 >= -2147483647 + P_24 and > P_24 >= -2147483648 and P_24 <= 2147483647 and P_23 >= 0 and P_23 <= > 18446744073709551615) } > > [P_24, P_23] -> { [i0, i1, i2] -> separate[o0] } > > ISL AST generated by ISL: > > for (int c1 = 0; c1 < P_24; c1 += 1) > if ((P_23 + 8 * c1) % 18446744073709551616 >= 1) > S_13(c1); > > CLAST generated by CLooG: > > if (8*T_46 >= -T_45+9) { > for (scat_1=0;scat_1<=T_46-1;scat_1++) { > if ((8*scat_1+T_45+18446744073709551615)%18446744073709551616 <= > 18446744073709551614) { > (scat_1); > } > } > } > > isl_codegen: > > [P_46, P_45] -> { S_16[i0] -> [0, i0, 0] : exists (e0 = floor((-1 + > P_46)/4294967296), e1 = floor((P_45 + 8i0)/18446744073709551616): i0 >> >= 0 and 4294967296e0 <= -1 + P_46 and 4294967296e0 >= -4294967296 + > P_46 and 4294967296e0 <= -1 + P_46 - i0 and i0 <= 2147483646 and > 18446744073709551616e1 >= -18446744073709551615 + P_45 + 8i0 and > 18446744073709551616e1 <= -1 + P_45 + 8i0) } > > [P_46, P_45] -> { : exists (e0 = floor((-1 + P_46)/4294967296): > 4294967296e0 <= -1 + P_46 and 4294967296e0 >= -2147483647 + P_46 and > P_46 >= -2147483648 and P_46 <= 2147483647 and P_45 >= 0 and P_45 <= > 18446744073709551615) } > > [P_46, P_45] -> { [i0, i1, i2] -> separate[o0] } > > ISL AST generated by ISL: > > for (int c1 = 0; c1 < P_46; c1 += 1) > if ((P_45 + 8 * c1) % 18446744073709551616 >= 1) > S_16(c1); > > CLAST generated by CLooG: > > if (8*T_18 >= -T_17+9) { > for (scat_1=0;scat_1<=T_18-1;scat_1++) { > if ((8*scat_1+T_17+18446744073709551615)%18446744073709551616 <= > 18446744073709551614) { > (scat_1); > } > } > } > > isl_codegen: > > [P_18, P_17] -> { S_12[i0] -> [0, i0, 0] : exists (e0 = floor((-1 + > P_18)/4294967296), e1 = floor((P_17 + 8i0)/18446744073709551616): i0 >> >= 0 and 4294967296e0 <= -1 + P_18 and 4294967296e0 >= -4294967296 + > P_18 and 4294967296e0 <= -1 + P_18 - i0 and i0 <= 2147483646 and > 18446744073709551616e1 >= -18446744073709551615 + P_17 + 8i0 and > 18446744073709551616e1 <= -1 + P_17 + 8i0) } > > [P_18, P_17] -> { : exists (e0 = floor((-1 + P_18)/4294967296): > 4294967296e0 <= -1 + P_18 and 4294967296e0 >= -2147483647 + P_18 and > P_18 >= -2147483648 and P_18 <= 2147483647 and P_17 >= 0 and P_17 <= > 18446744073709551615) } > > [P_18, P_17] -> { [i0, i1, i2] -> separate[o0] } > > ISL AST generated by ISL: > > for (int c1 = 0; c1 < P_18; c1 += 1) > if ((P_17 + 8 * c1) % 18446744073709551616 >= 1) > S_12(c1); > > I think that, for example, the following code > > if (8*T_45 >= -T_44+9) { > for (scat_1=0;scat_1<=T_45-1;scat_1++) { > if ((8*scat_1+T_44+18446744073709551615)%18446744073709551616 <= > 18446744073709551614) { > (scat_1); > } > } > } > > is equivalent to > > if (8*T_45 >= -T_44+9) { > for (scat_1=0;scat_1<=T_45-1;scat_1++) { > if ((8*scat_1+T_44)%18446744073709551616 <= -1) { > (scat_1); > } > } > } > > If I'm not mistaken it's not equivalent to > > for (int c1 = 0; c1 < P_45; c1 += 1) > if ((P_44 + 8 * c1) % 18446744073709551616 >= 1) > S_12(c1); > > Maybe the ISL generator generates wrong code. What do you think about this? Possibly. Can you split the .cpp files such that you only compile a single function with graphite and that compiling this function causes the miscompile. This allows us to look at less code. Cheers, Tobias ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [GSoC] Elimination of CLooG library installation dependency 2014-08-08 13:16 ` Tobias Grosser @ 2014-08-09 7:42 ` Roman Gareev 2014-08-09 7:52 ` Tobias Grosser 0 siblings, 1 reply; 30+ messages in thread From: Roman Gareev @ 2014-08-09 7:42 UTC (permalink / raw) To: Tobias Grosser; +Cc: Mircea Namolaru, gcc-patches [-- Attachment #1: Type: text/plain, Size: 590 bytes --] > Is this segmentation fault at compile time or at run-time? I believe it was > a segfault at run-time due to a miscompile. Yes, it's a segfault at run-time. These source codes produce wrong object files. > Possibly. Can you split the .cpp files such that you only compile a single > function with graphite and that compiling this function causes the > miscompile. This allows us to look at less code. I've tried to reduce btCollisionWorld.cpp and btCollisionDispatcher.cpp (They can be found attached). Should we ask Sven? -- Cheers, Roman Gareev. [-- Attachment #2: btCollisionDispatcher.cpp.txt --] [-- Type: text/plain, Size: 888 bytes --] void *btAlignedAlloc (int size, int alignment); template <typename T, unsigned Alignment> class btAlignedAllocator { typedef btAlignedAllocator< T, Alignment> self_type; public: T *allocate (int n, const T** hint = 0) { (void) hint; return reinterpret_cast<T*>(btAlignedAlloc(sizeof (T) * n, Alignment)); } }; #include <new> template <typename T> class btAlignedObjectArray { btAlignedAllocator<T, 16> m_allocator; int m_size; T *m_data; public: void push_back () { T *s = (T*) m_allocator.allocate (m_size * 2); int i; for (i=0; i<m_size; ++i) new (&s[i]) T (m_data[i]); } }; class btCollisionDispatcher { btAlignedObjectArray<btCollisionDispatcher*> m_manifoldsPtr; virtual void getNewManifold (); }; void btCollisionDispatcher::getNewManifold () { m_manifoldsPtr.push_back (); } [-- Attachment #3: btCollisionWorld.cpp.txt --] [-- Type: text/plain, Size: 1326 bytes --] void* btAlignedAlloc (int size, int alignment); template <typename T, unsigned Alignment> class btAlignedAllocator { typedef btAlignedAllocator<T, Alignment> self_type; public: template <typename Other> btAlignedAllocator (const btAlignedAllocator<Other, Alignment>& ) {} T *allocate (int n, const T **hint = 0) { (void) hint; return reinterpret_cast<T*> (btAlignedAlloc (sizeof (T) * n , Alignment)); } }; #include <new> template <typename T> class btAlignedObjectArray { btAlignedAllocator<T, 16> m_allocator; int m_size; T *m_data; public: void push_back (const T& _Val) { T *s = (T*) m_allocator.allocate (m_size * 2); int i; for (i=0; i<m_size; ++i) new (&s[i]) T (m_data[i]); new (&m_data[m_size]) T (_Val); } }; typedef btAlignedObjectArray<class btCollisionObject*> btCollisionObjectArray; class btCollisionObject; class btCollisionWorld { protected: btAlignedObjectArray<btCollisionObject*> m_collisionObjects; public: virtual void addCollisionObject(btCollisionObject* collisionObject); }; void btCollisionWorld::addCollisionObject(btCollisionObject* collisionObject) { m_collisionObjects.push_back(collisionObject); } ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [GSoC] Elimination of CLooG library installation dependency 2014-08-09 7:42 ` Roman Gareev @ 2014-08-09 7:52 ` Tobias Grosser 2014-08-09 10:05 ` Roman Gareev 0 siblings, 1 reply; 30+ messages in thread From: Tobias Grosser @ 2014-08-09 7:52 UTC (permalink / raw) To: Roman Gareev; +Cc: Mircea Namolaru, gcc-patches On 09/08/2014 09:42, Roman Gareev wrote: >> Is this segmentation fault at compile time or at run-time? I believe it was >> a segfault at run-time due to a miscompile. > > Yes, it's a segfault at run-time. These source codes produce wrong object files. > >> Possibly. Can you split the .cpp files such that you only compile a single >> function with graphite and that compiling this function causes the >> miscompile. This allows us to look at less code. > > I've tried to reduce btCollisionWorld.cpp and > btCollisionDispatcher.cpp (They can be found attached). Should we ask > Sven? With just C++ code, Sven can help little. He has no knowledge about graphite internals. Do you now have a setup where you can just compile one of the attached files with graphite and everything else without and the code crashes? Why did you provide two files. I assume one should be sufficient to reproduce the crash, no? I think for the one file you choose, it would be interesting to look at the code generation input as well as the kernels generated by CLooG and isl. Maybe we can understand what is going on. Cheers, Tobias ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [GSoC] Elimination of CLooG library installation dependency 2014-08-09 7:52 ` Tobias Grosser @ 2014-08-09 10:05 ` Roman Gareev 2014-08-11 6:26 ` Tobias Grosser 0 siblings, 1 reply; 30+ messages in thread From: Roman Gareev @ 2014-08-09 10:05 UTC (permalink / raw) To: Tobias Grosser; +Cc: Mircea Namolaru, gcc-patches > With just C++ code, Sven can help little. He has no knowledge about graphite > internals. I want to ask him about correctness of ISL ASTs generated from mentioned isl_codegens. > Do you now have a setup where you can just compile one of the attached files > with graphite and everything else without and the code crashes? No, I don't. As I mentioned earlier, all the files from this test case individually produce object files which linked into the one executable, which cause “Segmentation fault (core dumped)” (It'll cause “Segmentation fault (core dumped)”, if we try to run it). I think that it's very difficult to detach the code, which would produce the executable and save the semantics of this big OOP project. Furthermore, there is a possibility that the detached code can produce no new useful information. I've found that if we try to compile any of the btCollisionWorld.cpp, btCollisionDispatcher.cpp and btDiscreteDynamicsWorld.llvm.cpp by modified Graphite, the produced object file will lead to creation of the wrong executable (after linking with other object files generated by origin Graphite). That's why I think that we could consider only, for example, btCollisionDispatcher.cpp. It contains only one scope, which is incorrectly processed by Graphite with the ISL code generator as the main generator. > Why did you provide two files. I assume one should be sufficient to > reproduce the crash, no? I've detached the code, which is used by Graphite to produce similar AST's. > I think for the one file you choose, it would be interesting to look > at the code generation input as well as the kernels generated by CLooG and > isl. Maybe we can understand what is going on. What do you mean by the kernels generated by CLooG and isl? btCollisionDispatcher.cpp: isl_codegen: [P_2, P_11] -> { S_6[i0] -> [0, i0, 0] : exists (e0 = floor((-1 + P_2)/4294967296), e1 = floor((P_11 + 8i0)/18446744073709551616): i0 >= 0 and 4294967296e0 <= -1 + P_2 and 4294967296e0 >= -4294967296 + P_2 and 4294967296e0 <= -1 + P_2 - i0 and i0 <= 2147483646 and 18446744073709551616e1 >= -18446744073709551615 + P_11 + 8i0 and 18446744073709551616e1 <= -1 + P_11 + 8i0) } [P_2, P_11] -> { : exists (e0 = floor((-1 + P_2)/4294967296): 4294967296e0 <= -1 + P_2 and 4294967296e0 >= -2147483647 + P_2 and P_2 >= -2147483648 and P_2 <= 2147483647 and P_11 >= 0 and P_11 <= 18446744073709551615) } [P_2, P_11] -> { [i0, i1, i2] -> separate[o0] } ISL AST generated by ISL: for (int c1 = 0; c1 < P_2; c1 += 1) if ((P_11 + 8 * c1) % 18446744073709551616 >= 1) S_6(c1); cloog_input: # CLooG -> CLooG # This is an automatic dump of a CLooG input file from a CloogInput data # structure. # Language: C c # Context: 1 4 4 0 0 0 2 1 1 0 -1 1 -1 0 2147483647 1 0 -1 18446744073709551615 1 0 1 0 1 # Parameter name(s) T_2 T_11 # Statement number: 1 # Iteration domain of statement 1 (). 1 7 7 1 0 2 2 1 1 0 0 0 0 0 1 0 -4294967296 0 1 0 -1 1 0 4294967296 0 -1 0 4294967296 1 -1 -4294967296 0 1 0 -1 1 -1 0 0 0 0 2147483646 1 -8 0 18446744073709551616 0 -1 18446744073709551615 1 8 0 -18446744073709551616 0 1 -1 0 0 0 # For future options. 1 # Iterator name(s) git_0 # --------------------- SCATTERING -------------------- 1 # Scattering functions # Scattering of statement 1 (). 1 3 8 3 1 0 2 0 0 0 1 0 0 0 0 0 0 1 0 -1 0 0 0 0 1 0 0 0 0 0 0 1 # Scattering dimension name(s) scat_0 scat_1 scat_2 CLAST generated by ClooG: if (8*T_2 >= -T_11+9) { for (scat_1=0;scat_1<=T_2-1;scat_1++) { if ((8*scat_1+T_11+18446744073709551615)%18446744073709551616 <= 18446744073709551614) { (scat_1); } } } -- Cheers, Roman Gareev. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [GSoC] Elimination of CLooG library installation dependency 2014-08-09 10:05 ` Roman Gareev @ 2014-08-11 6:26 ` Tobias Grosser 2014-08-11 7:11 ` Roman Gareev 0 siblings, 1 reply; 30+ messages in thread From: Tobias Grosser @ 2014-08-11 6:26 UTC (permalink / raw) To: Roman Gareev; +Cc: Mircea Namolaru, gcc-patches On 09/08/2014 12:05, Roman Gareev wrote: >> With just C++ code, Sven can help little. He has no knowledge about graphite >> internals. > > I want to ask him about correctness of ISL ASTs generated from > mentioned isl_codegens. I am not sure if he can see it just like this. >> Do you now have a setup where you can just compile one of the attached files >> with graphite and everything else without and the code crashes? > > No, I don't. As I mentioned earlier, all the files from this test case > individually produce object files which linked into the one > executable, which cause “Segmentation fault (core dumped)†(It'll > cause “Segmentation fault (core dumped)â€, if we try to run it). I > think that it's very difficult to detach the code, which would produce > the executable and save the semantics of this big OOP project. > Furthermore, there is a possibility that the detached code can produce > no new useful information. > > I've found that if we try to compile any of the btCollisionWorld.cpp, > btCollisionDispatcher.cpp > and btDiscreteDynamicsWorld.llvm.cpp by modified Graphite, the > produced object file will lead to creation of the wrong executable > (after linking with other object files generated by origin Graphite). I am confused. It seems you attached some kind of reduced version of btCollisionWorld.cpp? How did you obtain it? Did you compile and test with these versions? > That's why I think that we could consider only, for example, > btCollisionDispatcher.cpp. It contains only one scope, which is > incorrectly processed by Graphite with the ISL code generator as the > main generator. > >> Why did you provide two files. I assume one should be sufficient to >> reproduce the crash, no? > > I've detached the code, which is used by Graphite to produce similar AST's. OK. But did you check if they actually segfault or fail? >> I think for the one file you choose, it would be interesting to look >> at the code generation input as well as the kernels generated by CLooG and >> isl. Maybe we can understand what is going on. Yes, exactly those that you provided. At a first look, I don't see anything obvious wrong, except that the huge modulo values, which arise from some integer wrapping support Sebastian added once for unsigned integers. I see two approaches you can take: 1) The easy one Disallow unsigned integers in the scop detection. I have doubts we can do anything good with those huge modulo constraints placed all over the generated code 2) Try to understand the test case I would try a couple of easy unsigned int loops to see if we can handle them properly. Something like: for (unsigned long i = 0; i < M; i++) A[i] += i; At best, we could even write your test case as such a loop and reproduce the bug outside of this huge C++ code. Maybe looking at the GIMPLE allows you to write C code that has similar behavior and where we could check the output? Tobias ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [GSoC] Elimination of CLooG library installation dependency 2014-08-11 6:26 ` Tobias Grosser @ 2014-08-11 7:11 ` Roman Gareev 2014-08-11 7:27 ` Tobias Grosser 0 siblings, 1 reply; 30+ messages in thread From: Roman Gareev @ 2014-08-11 7:11 UTC (permalink / raw) To: Tobias Grosser; +Cc: Mircea Namolaru, gcc-patches [-- Attachment #1: Type: text/plain, Size: 4554 bytes --] > I am confused. It seems you attached some kind of reduced version of > btCollisionWorld.cpp? How did you obtain it? Did you compile and test > with these versions? I’ve manually selected parts of code, which produce the scope. I’ve found out that this bug is most probably caused by absence of pointer handling. The tree, which is corresponding to P_11 has pointer type. Furthermore, if we consider the transformed gimple code for (it can be found attached), we’ll see that it contains wrong parts: The code produced by modified version of Graphite: ... _35 = (signed long) _11; _36 = _34 + _35; _37 = _36 % 0; _38 = _37 > 0; _39 = (signed long) _38; ... The code produced by origin version of Graphite: ... _36 = (sizetype) _11; _37 = _36 + 18446744073709551615; _38 = 8B + _37; _39 = _38 % 0B; _40 = _39 != -1B; ... (If I’m not mistaken, 0B, for example, corresponds to (void *). It can be seen here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50712) I’ve tried to implement pointer handling in the attached patch, but it is wrong. I get the following error instead of seagfault now: Floating point exception (core dumped) back trace: Program terminated with signal 8, Arithmetic exception. #0 0x00000000004204c5 in allocSize (this=<optimized out>, size=<optimized out>) at /home/roman/llvm-test-suite/MultiSource/Benchmarks/Bullet/include/LinearMath/btAlignedObjectArray.h:59 59 return (size ? size*2 : 1); (gdb) bt #0 0x00000000004204c5 in allocSize (this=<optimized out>, size=<optimized out>) at /home/roman/llvm-test-suite/MultiSource/Benchmarks/Bullet/include/LinearMath/btAlignedObjectArray.h:59 #1 push_back (_Val=<synthetic pointer>, this=0x1125600) at /home/roman/llvm-test-suite/MultiSource/Benchmarks/Bullet/include/LinearMath/btAlignedObjectArray.h:220 #2 btCollisionDispatcher::getNewManifold (this=0x11255f0, b0=<optimized out>, b1=<optimized out>) at btCollisionDispatcher.llvm.cpp:100 #3 0x000000000044e764 in btConvexPlaneCollisionAlgorithm::btConvexPlaneCollisionAlgorithm (this=0x7f665ca6b0c0, mf=0x0, ci=..., col0=<optimized out>, col1=<optimized out>, isSwapped=<optimized out>, numPerturbationIterations=1, minimumPointsPerturbationThreshold=1) at /home/roman/llvm-test-suite/MultiSource/Benchmarks/Bullet/btConvexPlaneCollisionAlgorithm.cpp:38 #4 0x000000000046281b in btConvexPlaneCollisionAlgorithm::CreateFunc::CreateCollisionAlgorithm (this=0x11254e0, ci=..., body0=0x113d040, body1=0x113d810) at /home/roman/llvm-test-suite/MultiSource/Benchmarks/Bullet/include/BulletCollision/CollisionDispatch/btConvexPlaneCollisionAlgorithm.h:76 #5 0x00000000004205ac in btCollisionDispatcher::findAlgorithm ( this=<optimized out>, body0=<optimized out>, body1=<optimized out>, sharedManifold=<optimized out>) at btCollisionDispatcher.llvm.cpp:145 #6 0x00000000004202e2 in btCollisionDispatcher::defaultNearCallback ( ---Type <return> to continue, or q <return> to quit--- collisionPair=..., dispatcher=..., dispatchInfo=...) at btCollisionDispatcher.llvm.cpp:258 #7 0x000000000042083b in btCollisionPairCallback::processOverlap ( this=<optimized out>, pair=...) at btCollisionDispatcher.llvm.cpp:224 #8 0x00000000004acff2 in btHashedOverlappingPairCache::processAllOverlappingPairs (this=0x1127f80, callback=0x7fff0d1af790, dispatcher=0x11255f0) at /home/roman/llvm-test-suite/MultiSource/Benchmarks/Bullet/btOverlappingPairCache.cpp:387 #9 0x00000000004200c9 in btCollisionDispatcher::dispatchAllCollisionPairs ( this=<optimized out>, pairCache=<optimized out>, dispatchInfo=..., dispatcher=<optimized out>) at btCollisionDispatcher.llvm.cpp:238 #10 0x0000000000421bd4 in btCollisionWorld::performDiscreteCollisionDetection() () #11 0x0000000000464d9a in btDiscreteDynamicsWorld::internalSingleStepSimulation(float) () #12 0x000000000046473f in btDiscreteDynamicsWorld::stepSimulation(float, int, float) () #13 0x0000000000401e08 in BenchmarkDemo::clientMoveAndDisplay ( this=0x7fff0d1af980) at /home/roman/llvm-test-suite/MultiSource/Benchmarks/Bullet/BenchmarkDemo.cpp:232 #14 0x0000000000401b12 in main (argc=<optimized out>, argv=<optimized out>) at /home/roman/llvm-test-suite/MultiSource/Benchmarks/Bullet/main.cpp:63 Could you please advise me an algorithm for pointer handling? -- Cheers, Roman Gareev. [-- Attachment #2: gimple_cloog.txt --] [-- Type: text/plain, Size: 5620 bytes --] loop_0 (header = 0, latch = 1, niter = ) { bb_2 (preds = {bb_0 }, succs = {bb_4 bb_3 }) { <bb 2>: # DEBUG D#5 => &this_1(D)->m_manifoldsPtr # DEBUG this => D#5 # VUSE <.MEM_3(D)> _5 = MEM[(struct btAlignedObjectArray *)this_1(D) + 8B].m_size; _6 = _5 * 2; # DEBUG D#4 => &D#5->m_allocator # DEBUG D#2 => D#4 # DEBUG D#3 => 0B # DEBUG n => _6 # DEBUG this => D#2 # DEBUG hint => D#3 _7 = (long unsigned int) _6; _8 = (unsigned int) _7; _9 = _8 * 8; _10 = (int) _9; # .MEM_22 = VDEF <.MEM_3(D)> _11 = btAlignedAlloc (_10, 16); # DEBUG s => _11 # DEBUG i => 0 # DEBUG i => 0 # VUSE <.MEM_22> _2 = MEM[(struct btAlignedObjectArray *)this_1(D) + 8B].m_size; if (_2 > 0) goto <bb 4>; else goto <bb 3>; } bb_3 (preds = {bb_2 bb_10 }, succs = {bb_11 }) { <bb 3>: # .MEM_21 = PHI <.MEM_22(2), .MEM_24(10)> } bb_11 (preds = {bb_3 }, succs = {bb_1 }) { <bb 11>: # VUSE <.MEM_21> return; } bb_4 (preds = {bb_2 }, succs = {bb_14 }) { <bb 4>: } bb_14 (preds = {bb_4 }, succs = {bb_18 bb_5 }) { <bb 14>: if (0 != 0) goto <bb 18>; else goto <bb 5>; } bb_18 (preds = {bb_14 }, succs = {bb_22 bb_21 }) { <bb 18>: _20 = -_11; _30 = _20 + 9; _31 = _30 <= 8B; if (_31 != 0) goto <bb 22>; else goto <bb 21>; } bb_21 (preds = {bb_18 }, succs = {bb_19 }) { <bb 21>: goto <bb 19>; } bb_22 (preds = {bb_18 }, succs = {bb_28 bb_25 }) { <bb 22>: _32 = _2 > 0; if (_32 != 0) goto <bb 28>; else goto <bb 25>; } bb_25 (preds = {bb_22 }, succs = {bb_23 }) { <bb 25>: goto <bb 23>; } bb_28 (preds = {bb_22 }, succs = {bb_26 }) { <bb 28>: _33 = _2 + -1; } bb_30 (preds = {bb_29 }, succs = {bb_24 }) { <bb 30>: } bb_24 (preds = {bb_30 }, succs = {bb_23 }) { <bb 24>: } bb_23 (preds = {bb_24 bb_25 }, succs = {bb_20 }) { <bb 23>: # .MEM_51 = PHI <.MEM_53(24), .MEM_22(25)> } bb_20 (preds = {bb_23 }, succs = {bb_19 }) { <bb 20>: } bb_19 (preds = {bb_20 bb_21 }, succs = {bb_16 }) { <bb 19>: # .MEM_50 = PHI <.MEM_51(20), .MEM_22(21)> } bb_16 (preds = {bb_19 }, succs = {bb_15 }) { <bb 16>: } bb_15 (preds = {bb_16 bb_8 }, succs = {bb_13 }) { <bb 15>: # .MEM_24 = PHI <.MEM_50(16), .MEM_12(8)> } bb_13 (preds = {bb_15 }, succs = {bb_12 }) { <bb 13>: goto <bb 12>; } bb_8 (preds = {bb_7 }, succs = {bb_15 }) { <bb 8>: # .MEM_12 = PHI <.MEM_4(7)> goto <bb 15>; } bb_12 (preds = {bb_13 }, succs = {bb_10 }) { <bb 12>: } bb_10 (preds = {bb_12 }, succs = {bb_3 }) { <bb 10>: goto <bb 3>; } loop_2 (header = 26, latch = 27, niter = ) { bb_26 (preds = {bb_28 bb_27 }, succs = {bb_31 }) { <bb 26>: # graphite_IV.7_34 = PHI <0(28), graphite_IV.7_35(27)> # .MEM_52 = PHI <.MEM_22(28), .MEM_53(27)> } bb_31 (preds = {bb_26 }, succs = {bb_35 bb_34 }) { <bb 31>: _36 = (sizetype) _11; _37 = _36 + 18446744073709551615; _38 = 8B + _37; _39 = _38 % 0B; _40 = _39 != -1B; if (_40 != 0) goto <bb 35>; else goto <bb 34>; } bb_34 (preds = {bb_31 }, succs = {bb_32 }) { <bb 34>: goto <bb 32>; } bb_35 (preds = {bb_31 }, succs = {bb_33 }) { <bb 35>: # VUSE <.MEM_52> _41 = MEM[(struct btAlignedObjectArray *)this_1(D) + 8B].m_data; _43 = (long unsigned int) graphite_IV.7_34; _44 = _43 * 8; _42 = _41 + _44; # VUSE <.MEM_52> _45 = *_42; _47 = (sizetype) graphite_IV.7_34; _48 = _47 * 8; _49 = _11 + _48; # .MEM_46 = VDEF <.MEM_52> MEM[(struct btCollisionDispatcher * *)_49] = _45; } bb_33 (preds = {bb_35 }, succs = {bb_32 }) { <bb 33>: } bb_32 (preds = {bb_33 bb_34 }, succs = {bb_29 }) { <bb 32>: # .MEM_53 = PHI <.MEM_46(33), .MEM_52(34)> } bb_29 (preds = {bb_32 }, succs = {bb_27 bb_30 }) { <bb 29>: graphite_IV.7_35 = graphite_IV.7_34 + 1; if (graphite_IV.7_34 < _33) goto <bb 27>; else goto <bb 30>; } bb_27 (preds = {bb_29 }, succs = {bb_26 }) { <bb 27>: goto <bb 26>; } } loop_1 (header = 5, latch = 9, niter = , upper_bound = 2147483646) { bb_5 (preds = {bb_14 bb_9 }, succs = {bb_6 bb_7 }) { <bb 5>: # i_26 = PHI <0(14), i_19(9)> # .MEM_27 = PHI <.MEM_22(14), .MEM_4(9)> # DEBUG i => i_26 _13 = (long unsigned int) i_26; _14 = _13 * 8; _15 = _11 + _14; # DEBUG D#1 => 8 # DEBUG __p => _15 # DEBUG D.2562 => D#1 if (_15 != 0B) goto <bb 6>; else goto <bb 7>; } bb_6 (preds = {bb_5 }, succs = {bb_7 }) { <bb 6>: # VUSE <.MEM_27> _16 = MEM[(struct btAlignedObjectArray *)this_1(D) + 8B].m_data; _17 = _16 + _14; # VUSE <.MEM_27> _18 = *_17; # .MEM_23 = VDEF <.MEM_27> MEM[(struct btCollisionDispatcher * *)_15] = _18; } bb_7 (preds = {bb_5 bb_6 }, succs = {bb_9 bb_8 }) { <bb 7>: # .MEM_4 = PHI <.MEM_27(5), .MEM_23(6)> i_19 = i_26 + 1; # DEBUG i => i_19 # DEBUG i => i_19 if (_2 > i_19) goto <bb 9>; else goto <bb 8>; } bb_9 (preds = {bb_7 }, succs = {bb_5 }) { <bb 9>: goto <bb 5>; } } } [-- Attachment #3: gimple_isl.txt --] [-- Type: text/plain, Size: 2736 bytes --] loop_0 (header = 0, latch = 1, niter = ) { bb_2 (preds = {bb_0 }, succs = {bb_4 bb_3 }) { <bb 2>: # DEBUG D#5 => &this_1(D)->m_manifoldsPtr # DEBUG this => D#5 # VUSE <.MEM_3(D)> _5 = MEM[(struct btAlignedObjectArray *)this_1(D) + 8B].m_size; _6 = _5 * 2; # DEBUG D#4 => &D#5->m_allocator # DEBUG D#2 => D#4 # DEBUG D#3 => 0B # DEBUG n => _6 # DEBUG this => D#2 # DEBUG hint => D#3 _7 = (long unsigned int) _6; _8 = (unsigned int) _7; _9 = _8 * 8; _10 = (int) _9; # .MEM_22 = VDEF <.MEM_3(D)> _11 = btAlignedAlloc (_10, 16); # DEBUG s => _11 # DEBUG i => 0 # DEBUG i => 0 # VUSE <.MEM_22> _2 = MEM[(struct btAlignedObjectArray *)this_1(D) + 8B].m_size; if (_2 > 0) goto <bb 4>; else goto <bb 3>; } bb_3 (preds = {bb_2 bb_10 }, succs = {bb_1 }) { <bb 3>: # .MEM_21 = PHI <.MEM_22(2), .MEM_49(10)> # VUSE <.MEM_21> return; } bb_4 (preds = {bb_2 }, succs = {bb_5 bb_10 }) { <bb 4>: _20 = _2 > 0; if (_20 != 0) goto <bb 5>; else goto <bb 10>; } bb_5 (preds = {bb_4 }, succs = {bb_6 }) { <bb 5>: _30 = (signed long) _2; _31 = _30 + -1; } bb_10 (preds = {bb_8 bb_4 }, succs = {bb_3 }) { <bb 10>: # .MEM_49 = PHI <.MEM_51(8), .MEM_22(4)> goto <bb 3>; } loop_2 (header = 6, latch = 9, niter = (unsigned long) ((signed long) _2 + -1), upper_bound = 1152921504606846975) { bb_6 (preds = {bb_5 bb_9 }, succs = {bb_7 bb_8 }) { <bb 6>: # graphite_IV.7_32 = PHI <0(5), graphite_IV.7_33(9)> # .MEM_50 = PHI <.MEM_22(5), .MEM_51(9)> _34 = graphite_IV.7_32 * 8; _35 = (signed long) _11; _36 = _34 + _35; _37 = _36 % 0; _38 = _37 > 0; _39 = (signed long) _38; if (_39 != 0) goto <bb 7>; else goto <bb 8>; } bb_7 (preds = {bb_6 }, succs = {bb_8 }) { <bb 7>: # VUSE <.MEM_50> _40 = MEM[(struct btAlignedObjectArray *)this_1(D) + 8B].m_data; _42 = (long unsigned int) graphite_IV.7_32; _43 = _42 * 8; _41 = _40 + _43; # VUSE <.MEM_50> _44 = *_41; _46 = (sizetype) graphite_IV.7_32; _47 = _46 * 8; _48 = _11 + _47; # .MEM_45 = VDEF <.MEM_50> MEM[(struct btCollisionDispatcher * *)_48] = _44; } bb_8 (preds = {bb_7 bb_6 }, succs = {bb_9 bb_10 }) { <bb 8>: # .MEM_51 = PHI <.MEM_45(7), .MEM_50(6)> graphite_IV.7_33 = graphite_IV.7_32 + 1; if (graphite_IV.7_32 < _31) goto <bb 9>; else goto <bb 10>; } bb_9 (preds = {bb_8 }, succs = {bb_6 }) { <bb 9>: goto <bb 6>; } } } [-- Attachment #4: patch.txt --] [-- Type: text/plain, Size: 4821 bytes --] Index: gcc/graphite-isl-ast-to-gimple.c =================================================================== --- gcc/graphite-isl-ast-to-gimple.c (revision 213774) +++ gcc/graphite-isl-ast-to-gimple.c (working copy) @@ -150,6 +150,8 @@ gcc_assert (res != ip.end () && "Could not map isl_id to tree expression"); isl_ast_expr_free (expr_id); + if (POINTER_TYPE_P (TREE_TYPE (res->second))) + return res->second; return fold_convert (type, res->second); } @@ -178,18 +180,46 @@ type TYPE. */ static tree -binary_op_to_tree (tree type, __isl_take isl_ast_expr *expr, ivs_params &ip) +binary_op_to_tree (tree recommended_type, __isl_take isl_ast_expr *expr, + ivs_params &ip) { isl_ast_expr *arg_expr = isl_ast_expr_get_op_arg (expr, 0); - tree tree_lhs_expr = gcc_expression_from_isl_expression (type, arg_expr, ip); + tree tree_lhs_expr = + gcc_expression_from_isl_expression (recommended_type, arg_expr, ip); arg_expr = isl_ast_expr_get_op_arg (expr, 1); - tree tree_rhs_expr = gcc_expression_from_isl_expression (type, arg_expr, ip); + tree tree_rhs_expr = + gcc_expression_from_isl_expression (recommended_type, arg_expr, ip); + tree type = POINTER_TYPE_P (TREE_TYPE (tree_lhs_expr)) ? + TREE_TYPE (tree_lhs_expr) : recommended_type; + type = POINTER_TYPE_P (TREE_TYPE (tree_rhs_expr)) ? + TREE_TYPE (tree_rhs_expr) : type; + if (POINTER_TYPE_P (type)) + { + if (isl_ast_expr_get_op_type (expr) == isl_ast_op_add || + isl_ast_expr_get_op_type (expr) == isl_ast_op_mul || + isl_ast_expr_get_op_type (expr) == isl_ast_op_div) + { + if (!POINTER_TYPE_P (TREE_TYPE (tree_lhs_expr))) + tree_lhs_expr = fold_convert (sizetype, tree_lhs_expr); + if (!POINTER_TYPE_P (TREE_TYPE (tree_rhs_expr))) + tree_rhs_expr = fold_convert (sizetype, tree_rhs_expr); + } + else + { + tree_lhs_expr = fold_convert (type, tree_lhs_expr); + tree_rhs_expr = fold_convert (type, tree_rhs_expr); + } + } enum isl_ast_op_type expr_type = isl_ast_expr_get_op_type (expr); isl_ast_expr_free (expr); switch (expr_type) { case isl_ast_op_add: - return fold_build2 (PLUS_EXPR, type, tree_lhs_expr, tree_rhs_expr); + if (POINTER_TYPE_P (type)) + return fold_build2 (POINTER_PLUS_EXPR, type, tree_lhs_expr, + tree_rhs_expr); + else + return fold_build2 (PLUS_EXPR, type, tree_lhs_expr, tree_rhs_expr); case isl_ast_op_sub: return fold_build2 (MINUS_EXPR, type, tree_lhs_expr, tree_rhs_expr); @@ -210,26 +240,32 @@ return fold_build2 (FLOOR_DIV_EXPR, type, tree_lhs_expr, tree_rhs_expr); case isl_ast_op_and: - return fold_build2 (TRUTH_ANDIF_EXPR, type, + return fold_build2 (TRUTH_ANDIF_EXPR, boolean_type_node, tree_lhs_expr, tree_rhs_expr); case isl_ast_op_or: - return fold_build2 (TRUTH_ORIF_EXPR, type, tree_lhs_expr, tree_rhs_expr); + return fold_build2 (TRUTH_ORIF_EXPR, boolean_type_node, tree_lhs_expr, + tree_rhs_expr); case isl_ast_op_eq: - return fold_build2 (EQ_EXPR, type, tree_lhs_expr, tree_rhs_expr); + return fold_build2 (EQ_EXPR, boolean_type_node, tree_lhs_expr, + tree_rhs_expr); case isl_ast_op_le: - return fold_build2 (LE_EXPR, type, tree_lhs_expr, tree_rhs_expr); + return fold_build2 (LE_EXPR, boolean_type_node, tree_lhs_expr, + tree_rhs_expr); case isl_ast_op_lt: - return fold_build2 (LT_EXPR, type, tree_lhs_expr, tree_rhs_expr); + return fold_build2 (LT_EXPR, boolean_type_node, tree_lhs_expr, + tree_rhs_expr); case isl_ast_op_ge: - return fold_build2 (GE_EXPR, type, tree_lhs_expr, tree_rhs_expr); + return fold_build2 (GE_EXPR, boolean_type_node, tree_lhs_expr, + tree_rhs_expr); case isl_ast_op_gt: - return fold_build2 (GT_EXPR, type, tree_lhs_expr, tree_rhs_expr); + return fold_build2 (GT_EXPR, boolean_type_node, tree_lhs_expr, + tree_rhs_expr); default: gcc_unreachable (); @@ -261,12 +297,16 @@ type TYPE. */ static tree -unary_op_to_tree (tree type, __isl_take isl_ast_expr *expr, ivs_params &ip) +unary_op_to_tree (tree recommended_type, __isl_take isl_ast_expr *expr, + ivs_params &ip) { gcc_assert (isl_ast_expr_get_op_type (expr) == isl_ast_op_minus); isl_ast_expr *arg_expr = isl_ast_expr_get_op_arg (expr, 0); - tree tree_expr = gcc_expression_from_isl_expression (type, arg_expr, ip); + tree tree_expr = + gcc_expression_from_isl_expression (recommended_type, arg_expr, ip); isl_ast_expr_free (expr); + tree type = POINTER_TYPE_P (TREE_TYPE (tree_expr)) ? + TREE_TYPE (tree_expr) : recommended_type; return fold_build1 (NEGATE_EXPR, type, tree_expr); } ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [GSoC] Elimination of CLooG library installation dependency 2014-08-11 7:11 ` Roman Gareev @ 2014-08-11 7:27 ` Tobias Grosser 2014-08-11 14:20 ` Roman Gareev 0 siblings, 1 reply; 30+ messages in thread From: Tobias Grosser @ 2014-08-11 7:27 UTC (permalink / raw) To: Roman Gareev; +Cc: Mircea Namolaru, gcc-patches On 11/08/2014 09:11, Roman Gareev wrote: >> I am confused. It seems you attached some kind of reduced version of >> btCollisionWorld.cpp? How did you obtain it? Did you compile and test >> with these versions? > > IÂ’ve manually selected parts of code, which produce the scope. > > IÂ’ve found out that this bug is most probably caused by absence of > pointer handling. The tree, which is corresponding to P_11 has > pointer type. Furthermore, if we consider the transformed gimple code > for (it can be found attached), weÂ’ll see that it contains wrong > parts: > > > Could you please advise me an algorithm for pointer handling? Did you try your code with 64bit pointer types? In any case, I don't think it is worth spending time on this. I would check in the scop detection that we disable the handling of unsigned and pointer types. It is a complex thing to model and the approach currently taking of always model their wrapping behaviour seems wrong. What we should do later is to build a run-time check that ensures no pointer overflow is happening and then just create code without it. Cheers, Tobias ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [GSoC] Elimination of CLooG library installation dependency 2014-08-11 7:27 ` Tobias Grosser @ 2014-08-11 14:20 ` Roman Gareev 2014-08-13 8:07 ` Roman Gareev 0 siblings, 1 reply; 30+ messages in thread From: Roman Gareev @ 2014-08-11 14:20 UTC (permalink / raw) To: Tobias Grosser; +Cc: Mircea Namolaru, gcc-patches [-- Attachment #1: Type: text/plain, Size: 793 bytes --] > Did you try your code with 64bit pointer types? Yes. It seems that the result is the same. > In any case, I don't think it is worth spending time on this. I would check > in the scop detection that we disable the handling of unsigned and pointer > types. It is a complex thing to model and the approach currently taking of > always model their wrapping behaviour seems wrong. I’ve attached a patch, which disables the handling SSA_NAME nodes in case they are pointers to object types. Which nodes should also be disabled? (I’ve found that this disabling helps to avoid the error and can be a temporary solution) Is the graphite_can_represent_scev an appropriate place for the disabling of type handling? -- Cheers, Roman Gareev. [-- Attachment #2: patch.txt --] [-- Type: text/plain, Size: 610 bytes --] Index: gcc/graphite-scop-detection.c =================================================================== --- gcc/graphite-scop-detection.c (revision 213773) +++ gcc/graphite-scop-detection.c (working copy) @@ -54,6 +54,7 @@ #include "tree-pass.h" #include "sese.h" #include "tree-ssa-propagate.h" +#include "cp/cp-tree.h" #ifdef HAVE_cloog #include "graphite-poly.h" @@ -217,6 +218,9 @@ if (chrec_contains_undetermined (scev)) return false; + if (TYPE_PTROB_P (TREE_TYPE (scev)) && TREE_CODE (scev) == SSA_NAME) + return false; + switch (TREE_CODE (scev)) { case NEGATE_EXPR: ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [GSoC] Elimination of CLooG library installation dependency 2014-08-11 14:20 ` Roman Gareev @ 2014-08-13 8:07 ` Roman Gareev 2014-08-13 8:56 ` Tobias Grosser 2014-08-13 9:55 ` Richard Biener 0 siblings, 2 replies; 30+ messages in thread From: Roman Gareev @ 2014-08-13 8:07 UTC (permalink / raw) To: Tobias Grosser; +Cc: Mircea Namolaru, gcc-patches [-- Attachment #1: Type: text/plain, Size: 1444 bytes --] If I’m not mistaken all tree nodes, which have pointer type, can be divided into two groups: the type is a is a pointer to data member (TYPE_PTRMEM_P is true for it), the type is a pointer type, and the pointee is not a data member (TYPE_PTR_P is true for it). I think that we’re interested in disabling of the second group handling. It can also be divided into two groups: the type is a pointer to function type (TYPE_PTRFN_P is true for it), the type is a pointer to object type (TYPE_PTROB_P is true for it). In my opinion, the second one is worth to be considered. It contains, for example, nop_expr (these nodes are used to represent conversions that do not require any code-generation) integer_cst (these nodes represent integer constants), ssa_name. I haven’t found all types, which are contained in it. However, I think that we could disable other types, if it is necessary in the future. > What we should do later is to build a run-time check that ensures > no pointer overflow is happening and then just create code without it. I think that it is better to do this when the pointer handling is completed. I’ve attached a Change_Log, which corresponds to the previous patch. Are they fine for trunk? Could we give a headsup on the GCC mailing list and ask other people to try the new isl support in case this patch is committed? -- Cheers, Roman Gareev. [-- Attachment #2: ChangeLog_entry.txt --] [-- Type: text/plain, Size: 232 bytes --] 2014-07-12 Roman Gareev <gareevroman@gmail.com> gcc/ * graphite-scop-detection.c: Add inclusion of cp-tree.h. (graphite_can_represent_scev): Disables the handling of SSA_NAME nodes in case they are pointers to object types. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [GSoC] Elimination of CLooG library installation dependency 2014-08-13 8:07 ` Roman Gareev @ 2014-08-13 8:56 ` Tobias Grosser 2014-08-13 11:48 ` Roman Gareev 2014-08-13 9:55 ` Richard Biener 1 sibling, 1 reply; 30+ messages in thread From: Tobias Grosser @ 2014-08-13 8:56 UTC (permalink / raw) To: Roman Gareev; +Cc: Mircea Namolaru, gcc-patches On 13/08/2014 16:07, Roman Gareev wrote: > If IÂ’m not mistaken all tree nodes, which have pointer type, can be > divided into two groups: the type is a is a pointer to data member > (TYPE_PTRMEM_P is true for it), the type is a pointer type, and the > pointee is not a data member (TYPE_PTR_P is true for it). I think that > weÂ’re interested in disabling of the second group handling. It can > also be divided into two groups: the type is a pointer to function > type (TYPE_PTRFN_P is true for it), the type is a pointer to object > type (TYPE_PTROB_P is true for it). In my opinion, the second one is > worth to be considered. It contains, for example, nop_expr (these > nodes are used to represent conversions that do not require any > code-generation) integer_cst (these nodes represent integer > constants), ssa_name. I havenÂ’t found all types, which are contained > in it. However, I think that we could disable other types, if it is > necessary in the future. > >> What we should do later is to build a run-time check that ensures >> no pointer overflow is happening and then just create code without it. > > I think that it is better to do this when the pointer handling is completed. > > IÂ’ve attached a Change_Log, which corresponds to the previous patch. > Are they fine for trunk? Could we give a headsup on the GCC mailing > list and ask other people to try the new isl support in case this > patch is committed? Two minor thinks: - I assume you verified this passes all graphite tests. - Please add a brief comment in the source code regarding why we do not want to detect such SCoPs. Otherwise LGTM. Cheers, Tobias ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [GSoC] Elimination of CLooG library installation dependency 2014-08-13 8:56 ` Tobias Grosser @ 2014-08-13 11:48 ` Roman Gareev 0 siblings, 0 replies; 30+ messages in thread From: Roman Gareev @ 2014-08-13 11:48 UTC (permalink / raw) To: Tobias Grosser; +Cc: Mircea Namolaru, gcc-patches > - I assume you verified this passes all graphite tests. Yes, I’ve found out that there is no regression. > - Please add a brief comment in the source code regarding why we > do not want to detect such SCoPs. Would you add anything to the following comment: “We disable the handling of pointer types, because it’s currently not supported by Graphite with the ISL AST generator. SSA_NAME nodes are the only nodes, which are disabled in case they are pointers to object types, but this can be changed.” ? -- Cheers, Roman Gareev. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [GSoC] Elimination of CLooG library installation dependency 2014-08-13 8:07 ` Roman Gareev 2014-08-13 8:56 ` Tobias Grosser @ 2014-08-13 9:55 ` Richard Biener 2014-08-13 11:49 ` Roman Gareev 1 sibling, 1 reply; 30+ messages in thread From: Richard Biener @ 2014-08-13 9:55 UTC (permalink / raw) To: Roman Gareev; +Cc: Tobias Grosser, Mircea Namolaru, GCC Patches On Wed, Aug 13, 2014 at 10:07 AM, Roman Gareev <gareevroman@gmail.com> wrote: > If I’m not mistaken all tree nodes, which have pointer type, can be > divided into two groups: the type is a is a pointer to data member > (TYPE_PTRMEM_P is true for it), the type is a pointer type, and the > pointee is not a data member (TYPE_PTR_P is true for it). Both are C++ frontend concepts and not relevant for the middle-end and thus GRAPHITE. I think that > we’re interested in disabling of the second group handling. It can > also be divided into two groups: the type is a pointer to function > type (TYPE_PTRFN_P is true for it), the type is a pointer to object > type (TYPE_PTROB_P is true for it). In my opinion, the second one is > worth to be considered. It contains, for example, nop_expr (these > nodes are used to represent conversions that do not require any > code-generation) integer_cst (these nodes represent integer > constants), ssa_name. I haven’t found all types, which are contained > in it. However, I think that we could disable other types, if it is > necessary in the future. > >> What we should do later is to build a run-time check that ensures >> no pointer overflow is happening and then just create code without it. I think you can assume that pointers don't overflow. Richard. > I think that it is better to do this when the pointer handling is completed. > > I’ve attached a Change_Log, which corresponds to the previous patch. > Are they fine for trunk? Could we give a headsup on the GCC mailing > list and ask other people to try the new isl support in case this > patch is committed? > > -- > Cheers, Roman Gareev. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [GSoC] Elimination of CLooG library installation dependency 2014-08-13 9:55 ` Richard Biener @ 2014-08-13 11:49 ` Roman Gareev 0 siblings, 0 replies; 30+ messages in thread From: Roman Gareev @ 2014-08-13 11:49 UTC (permalink / raw) To: Richard Biener; +Cc: Tobias Grosser, Mircea Namolaru, gcc-patches Thank you for the comment! 2014-08-13 15:55 GMT+06:00 Richard Biener <richard.guenther@gmail.com>: > On Wed, Aug 13, 2014 at 10:07 AM, Roman Gareev <gareevroman@gmail.com> wrote: >> If I’m not mistaken all tree nodes, which have pointer type, can be >> divided into two groups: the type is a is a pointer to data member >> (TYPE_PTRMEM_P is true for it), the type is a pointer type, and the >> pointee is not a data member (TYPE_PTR_P is true for it). > > Both are C++ frontend concepts and not relevant for the middle-end > and thus GRAPHITE. > > I think that >> we’re interested in disabling of the second group handling. It can >> also be divided into two groups: the type is a pointer to function >> type (TYPE_PTRFN_P is true for it), the type is a pointer to object >> type (TYPE_PTROB_P is true for it). In my opinion, the second one is >> worth to be considered. It contains, for example, nop_expr (these >> nodes are used to represent conversions that do not require any >> code-generation) integer_cst (these nodes represent integer >> constants), ssa_name. I haven’t found all types, which are contained >> in it. However, I think that we could disable other types, if it is >> necessary in the future. >> >>> What we should do later is to build a run-time check that ensures >>> no pointer overflow is happening and then just create code without it. > > I think you can assume that pointers don't overflow. > > Richard. > >> I think that it is better to do this when the pointer handling is completed. >> >> I’ve attached a Change_Log, which corresponds to the previous patch. >> Are they fine for trunk? Could we give a headsup on the GCC mailing >> list and ask other people to try the new isl support in case this >> patch is committed? >> >> -- >> Cheers, Roman Gareev. -- Cheers, Roman Gareev. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [GSoC] Elimination of CLooG library installation dependency 2014-08-06 15:22 [GSoC] Elimination of CLooG library installation dependency Roman Gareev 2014-08-06 15:48 ` Tobias Grosser @ 2014-08-15 11:13 ` Roman Gareev 2014-08-15 11:45 ` Richard Biener 2014-08-18 13:00 ` Richard Biener 1 sibling, 2 replies; 30+ messages in thread From: Roman Gareev @ 2014-08-15 11:13 UTC (permalink / raw) To: Tobias Grosser; +Cc: Mircea Namolaru, gcc-patches [-- Attachment #1: Type: text/plain, Size: 868 bytes --] > I've attached the patch, which should eliminate CLooG library > installation dependency from GCC. The CLooG AST generator is still the > main code generator, but the isl ast generator will be chosen in case > of nonavailability of CLooG library. > > However, I've found out a problem. Almost all the functions of the ISL > cannot be used without installed CLooG. (I get errors which contain > “undefined reference to...”). Maybe I missed something. What do you > think about this? I’ve attached a patch, which contains mentioned changes and doesn’t cause the error. I want to commit it in coming days. What do you think about it? Maybe we should make the ISL AST generator to be the main code generator of Graphite (the patch1 implements this). What do you think about it? -- Cheers, Roman Gareev. [-- Attachment #2: ChangeLog_entry.txt --] [-- Type: text/plain, Size: 914 bytes --] 2014-08-15 Roman Gareev <gareevroman@gmail.com> * configure.ac: Eliminate ClooG installation dependency. * configure: Regenerate. * Makefile.tpl: Add definition of ISLLIBS and HOST_ISLLIBS. * Makefile.in: Regenerate. [config/] * cloog.m4: Remove the path to isllibs from clooglibs. * isl.m4: Add paths to islinc, isllibs. [gcc/] * Makefile.in: Add definition of ISLLIBS. Update LIBS. * config.in: Add undef of HAVE_isl. * configure: Regenerate. * configure.ac: Add definition of HAVE_isl. * graphite-blocking.c: Add checking of HAVE_isl. * graphite-dependences.c: Likewise. * graphite-interchange.c: Likewise. * graphite-isl-ast-to-gimple.c: Likewise. * graphite-optimize-isl.c: Likewise. * graphite-poly.c: Likewise. * graphite-scop-detection.c: Likewise. * graphite-sese-to-poly.c: Likewise. * graphite.c: * toplev.c: Replace the checking of HAVE_cloog with the checking of HAVE_isl. [-- Attachment #3: ChangeLog_entry1.txt --] [-- Type: text/plain, Size: 144 bytes --] 2014-08-15 Roman Gareev <gareevroman@gmail.com> [gcc/] * common.opt: Make the ISL AST generator to be the main code generator of Graphite. [-- Attachment #4: patch.txt --] [-- Type: text/plain, Size: 17918 bytes --] Index: Makefile.in =================================================================== --- Makefile.in (revision 214008) +++ Makefile.in (working copy) @@ -219,6 +219,7 @@ HOST_LIBS="$(STAGE1_LIBS)"; export HOST_LIBS; \ GMPLIBS="$(HOST_GMPLIBS)"; export GMPLIBS; \ GMPINC="$(HOST_GMPINC)"; export GMPINC; \ + ISLLIBS="$(HOST_ISLLIBS)"; export ISLLIBS; \ ISLINC="$(HOST_ISLINC)"; export ISLINC; \ CLOOGLIBS="$(HOST_CLOOGLIBS)"; export CLOOGLIBS; \ CLOOGINC="$(HOST_CLOOGINC)"; export CLOOGINC; \ @@ -310,6 +311,7 @@ HOST_GMPINC = @gmpinc@ # Where to find ISL +HOST_ISLLIBS = @isllibs@ HOST_ISLINC = @islinc@ # Where to find CLOOG Index: Makefile.tpl =================================================================== --- Makefile.tpl (revision 214008) +++ Makefile.tpl (working copy) @@ -222,6 +222,7 @@ HOST_LIBS="$(STAGE1_LIBS)"; export HOST_LIBS; \ GMPLIBS="$(HOST_GMPLIBS)"; export GMPLIBS; \ GMPINC="$(HOST_GMPINC)"; export GMPINC; \ + ISLLIBS="$(HOST_ISLLIBS)"; export ISLLIBS; \ ISLINC="$(HOST_ISLINC)"; export ISLINC; \ CLOOGLIBS="$(HOST_CLOOGLIBS)"; export CLOOGLIBS; \ CLOOGINC="$(HOST_CLOOGINC)"; export CLOOGINC; \ @@ -313,6 +314,7 @@ HOST_GMPINC = @gmpinc@ # Where to find ISL +HOST_ISLLIBS = @isllibs@ HOST_ISLINC = @islinc@ # Where to find CLOOG Index: config/cloog.m4 =================================================================== --- config/cloog.m4 (revision 214008) +++ config/cloog.m4 (working copy) @@ -69,7 +69,7 @@ fi clooginc="-DCLOOG_INT_GMP ${clooginc}" - clooglibs="${clooglibs} -lcloog-isl ${isllibs} -lisl" + clooglibs="${clooglibs} -lcloog-isl" ] ) Index: config/isl.m4 =================================================================== --- config/isl.m4 (revision 214008) +++ config/isl.m4 (working copy) @@ -68,6 +68,9 @@ ENABLE_ISL_CHECK=no AC_MSG_WARN([using in-tree ISL, disabling version check]) fi + + islinc="-DCLOOG_INT_GMP ${islinc}" + isllibs="${isllibs} -lisl" ] ) Index: configure =================================================================== --- configure (revision 214008) +++ configure (working copy) @@ -649,6 +649,7 @@ clooginc clooglibs islinc +isllibs poststage1_ldflags poststage1_libs stage1_ldflags @@ -2760,7 +2761,7 @@ build_tools="build-texinfo build-flex build-bison build-m4 build-fixincludes" # these libraries are used by various programs built for the host environment -# +#f host_libs="intl libiberty opcodes bfd readline tcl tk itcl libgui zlib libbacktrace libcpp libdecnumber gmp mpfr mpc isl cloog libelf libiconv" # these tools are built for the host environment @@ -5835,10 +5836,9 @@ fi -# Treat either --without-cloog or --without-isl as a request to disable +# Treat --without-isl as a request to disable # GRAPHITE support and skip all following checks. -if test "x$with_isl" != "xno" && - test "x$with_cloog" != "xno"; then +if test "x$with_isl" != "xno"; then # Check for ISL @@ -5890,8 +5890,11 @@ $as_echo "$as_me: WARNING: using in-tree ISL, disabling version check" >&2;} fi + islinc="-DCLOOG_INT_GMP ${islinc}" + isllibs="${isllibs} -lisl" + if test "${ENABLE_ISL_CHECK}" = yes ; then _isl_saved_CFLAGS=$CFLAGS _isl_saved_LDFLAGS=$LDFLAGS @@ -6021,7 +6024,7 @@ fi clooginc="-DCLOOG_INT_GMP ${clooginc}" - clooglibs="${clooglibs} -lcloog-isl ${isllibs} -lisl" + clooglibs="${clooglibs} -lcloog-isl" @@ -6098,11 +6101,9 @@ fi fi -# If either the ISL or the CLooG check failed, disable builds of in-tree -# variants of both +# If the ISL check failed, disable builds of in-tree +# variants of both ISL and CLooG if test "x$with_isl" = xno || - test "x$with_cloog" = xno || - test "x$gcc_cv_cloog" = xno || test "x$gcc_cv_isl" = xno; then noconfigdirs="$noconfigdirs cloog isl" islinc= @@ -6110,11 +6111,20 @@ clooglibs= fi +# If the CLooG check failed, disable builds of in-tree +# variants of CLooG +if test "x$with_cloog" = xno || + test "x$gcc_cv_cloog" = xno; then + noconfigdirs="$noconfigdirs cloog isl" + clooginc= + clooglibs= +fi + # Check for LTO support. # Check whether --enable-lto was given. if test "${enable_lto+set}" = set; then : @@ -7325,7 +7335,7 @@ case $lib in - mpc | mpfr | gmp | cloog) + mpc | mpfr | gmp | isl | cloog) # If we're processing --with-$lib, --with-$lib-include or # --with-$lib-lib, for one of the libs above, and target is # different from host, don't pass the current argument to any Index: configure.ac =================================================================== --- configure.ac (revision 214008) +++ configure.ac (working copy) @@ -132,7 +132,7 @@ build_tools="build-texinfo build-flex build-bison build-m4 build-fixincludes" # these libraries are used by various programs built for the host environment -# +#f host_libs="intl libiberty opcodes bfd readline tcl tk itcl libgui zlib libbacktrace libcpp libdecnumber gmp mpfr mpc isl cloog libelf libiconv" # these tools are built for the host environment @@ -1644,10 +1644,9 @@ Equivalent to --with-isl-include=PATH/include plus --with-isl-lib=PATH/lib])]) -# Treat either --without-cloog or --without-isl as a request to disable +# Treat --without-isl as a request to disable # GRAPHITE support and skip all following checks. -if test "x$with_isl" != "xno" && - test "x$with_cloog" != "xno"; then +if test "x$with_isl" != "xno"; then # Check for ISL dnl Provide configure switches and initialize islinc & isllibs dnl with user input. @@ -1672,11 +1671,9 @@ fi fi -# If either the ISL or the CLooG check failed, disable builds of in-tree -# variants of both +# If the ISL check failed, disable builds of in-tree +# variants of both ISL and CLooG if test "x$with_isl" = xno || - test "x$with_cloog" = xno || - test "x$gcc_cv_cloog" = xno || test "x$gcc_cv_isl" = xno; then noconfigdirs="$noconfigdirs cloog isl" islinc= @@ -1684,11 +1681,20 @@ clooglibs= fi +# If the CLooG check failed, disable builds of in-tree +# variants of CLooG +if test "x$with_cloog" = xno || + test "x$gcc_cv_cloog" = xno; then + noconfigdirs="$noconfigdirs cloog isl" + clooginc= + clooglibs= +fi + +AC_SUBST(isllibs) AC_SUBST(islinc) AC_SUBST(clooglibs) AC_SUBST(clooginc) - # Check for LTO support. AC_ARG_ENABLE(lto, [AS_HELP_STRING([--enable-lto], [enable link time optimization support])], @@ -2812,7 +2818,7 @@ changequote([,]) case $lib in - mpc | mpfr | gmp | cloog) + mpc | mpfr | gmp | isl | cloog) # If we're processing --with-$lib, --with-$lib-include or # --with-$lib-lib, for one of the libs above, and target is # different from host, don't pass the current argument to any Index: gcc/Makefile.in =================================================================== --- gcc/Makefile.in (revision 214008) +++ gcc/Makefile.in (working copy) @@ -335,6 +335,7 @@ GMPINC = @GMPINC@ # How to find ISL +ISLLIBS = @ISLLIBS@ ISLINC = @ISLINC@ # How to find CLOOG @@ -1011,7 +1012,7 @@ # and the system's installed libraries. LIBS = @LIBS@ libcommon.a $(CPPLIB) $(LIBINTL) $(LIBICONV) $(LIBBACKTRACE) \ $(LIBIBERTY) $(LIBDECNUMBER) $(HOST_LIBS) -BACKENDLIBS = $(CLOOGLIBS) $(GMPLIBS) $(PLUGINLIBS) $(HOST_LIBS) \ +BACKENDLIBS = $(CLOOGLIBS) $(ISLLIBS) $(GMPLIBS) $(PLUGINLIBS) $(HOST_LIBS) \ $(ZLIB) # Any system libraries needed just for GNAT. SYSLIBS = @GNAT_LIBEXC@ Index: gcc/config.in =================================================================== --- gcc/config.in (revision 214008) +++ gcc/config.in (working copy) @@ -1699,13 +1699,16 @@ #undef HAVE_WORKING_VFORK #endif +/* Define if isl is in use. */ +#ifndef USED_FOR_TARGET +#undef HAVE_isl +#endif /* Define if cloog is in use. */ #ifndef USED_FOR_TARGET #undef HAVE_cloog #endif - /* Define if F_SETLKW supported by fcntl. */ #ifndef USED_FOR_TARGET #undef HOST_HAS_F_SETLKW Index: gcc/configure =================================================================== --- gcc/configure (revision 214008) +++ gcc/configure (working copy) @@ -27888,9 +27888,14 @@ +if test "x${ISLLIBS}" != "x" ; then +$as_echo "#define HAVE_isl 1" >>confdefs.h +fi + + if test "x${CLOOGLIBS}" != "x" ; then $as_echo "#define HAVE_cloog 1" >>confdefs.h Index: gcc/configure.ac =================================================================== --- gcc/configure.ac (revision 214008) +++ gcc/configure.ac (working copy) @@ -5514,6 +5514,9 @@ AC_ARG_VAR(ISLLIBS,[How to link ISL]) AC_ARG_VAR(ISLINC,[How to find ISL include files]) +if test "x${ISLLIBS}" != "x" ; then + AC_DEFINE(HAVE_isl, 1, [Define if isl is in use.]) +fi AC_ARG_VAR(CLOOGLIBS,[How to link CLOOG]) AC_ARG_VAR(CLOOGINC,[How to find CLOOG include files]) Index: gcc/graphite-blocking.c =================================================================== --- gcc/graphite-blocking.c (revision 214008) +++ gcc/graphite-blocking.c (working copy) @@ -23,14 +23,16 @@ #include "config.h" -#ifdef HAVE_cloog +#ifdef HAVE_isl #include <isl/set.h> #include <isl/map.h> #include <isl/union_map.h> #include <isl/constraint.h> +#ifdef HAVE_cloog #include <cloog/cloog.h> #include <cloog/isl/domain.h> #endif +#endif #include "system.h" #include "coretypes.h" @@ -49,7 +51,7 @@ #include "tree-data-ref.h" #include "sese.h" -#ifdef HAVE_cloog +#ifdef HAVE_isl #include "graphite-poly.h" Index: gcc/graphite-dependences.c =================================================================== --- gcc/graphite-dependences.c (revision 214008) +++ gcc/graphite-dependences.c (working copy) @@ -21,15 +21,17 @@ #include "config.h" -#ifdef HAVE_cloog +#ifdef HAVE_isl #include <isl/set.h> #include <isl/map.h> #include <isl/union_map.h> #include <isl/flow.h> #include <isl/constraint.h> +#ifdef HAVE_cloog #include <cloog/cloog.h> #include <cloog/isl/domain.h> #endif +#endif #include "system.h" #include "coretypes.h" @@ -49,7 +51,7 @@ #include "tree-scalar-evolution.h" #include "sese.h" -#ifdef HAVE_cloog +#ifdef HAVE_isl #include "graphite-poly.h" #include "graphite-htab.h" @@ -630,6 +632,8 @@ return res; } +#ifdef HAVE_cloog + /* Return true when the loop at DEPTH carries dependences. BODY is the body of the loop. */ @@ -685,3 +689,4 @@ } #endif +#endif Index: gcc/graphite-interchange.c =================================================================== --- gcc/graphite-interchange.c (revision 214008) +++ gcc/graphite-interchange.c (working copy) @@ -23,7 +23,7 @@ #include "config.h" -#ifdef HAVE_cloog +#ifdef HAVE_isl #include <isl/aff.h> #include <isl/set.h> #include <isl/map.h> @@ -37,9 +37,11 @@ #if defined(__cplusplus) } #endif +#ifdef HAVE_cloog #include <cloog/cloog.h> #include <cloog/isl/domain.h> #endif +#endif #include "system.h" #include "coretypes.h" @@ -59,7 +61,7 @@ #include "tree-scalar-evolution.h" #include "sese.h" -#ifdef HAVE_cloog +#ifdef HAVE_isl #include "graphite-poly.h" /* XXX isl rewrite following comment */ Index: gcc/graphite-isl-ast-to-gimple.c =================================================================== --- gcc/graphite-isl-ast-to-gimple.c (revision 214008) +++ gcc/graphite-isl-ast-to-gimple.c (working copy) @@ -20,7 +20,7 @@ #include "config.h" -#ifdef HAVE_cloog +#ifdef HAVE_isl #include <isl/set.h> #include <isl/map.h> #include <isl/union_map.h> @@ -55,7 +55,7 @@ #include "tree-into-ssa.h" #include <map> -#ifdef HAVE_cloog +#ifdef HAVE_isl #include "graphite-poly.h" #include "graphite-isl-ast-to-gimple.h" Index: gcc/graphite-optimize-isl.c =================================================================== --- gcc/graphite-optimize-isl.c (revision 214008) +++ gcc/graphite-optimize-isl.c (working copy) @@ -20,7 +20,7 @@ #include "config.h" -#ifdef HAVE_cloog +#ifdef HAVE_isl #include <isl/set.h> #include <isl/map.h> #include <isl/union_map.h> @@ -48,7 +48,7 @@ #include "tree-scalar-evolution.h" #include "sese.h" -#ifdef HAVE_cloog +#ifdef HAVE_isl #include "graphite-poly.h" static isl_union_set * Index: gcc/graphite-poly.c =================================================================== --- gcc/graphite-poly.c (revision 214008) +++ gcc/graphite-poly.c (working copy) @@ -21,7 +21,7 @@ #include "config.h" -#ifdef HAVE_cloog +#ifdef HAVE_isl #include <isl/set.h> #include <isl/map.h> #include <isl/union_map.h> @@ -36,9 +36,11 @@ #if defined(__cplusplus) } #endif +#ifdef HAVE_cloog #include <cloog/cloog.h> #include <cloog/isl/domain.h> #endif +#endif #include "system.h" #include "coretypes.h" @@ -60,7 +62,7 @@ #include "tree-scalar-evolution.h" #include "sese.h" -#ifdef HAVE_cloog +#ifdef HAVE_isl #include "graphite-poly.h" #define OPENSCOP_MAX_STRING 256 Index: gcc/graphite-scop-detection.c =================================================================== --- gcc/graphite-scop-detection.c (revision 214008) +++ gcc/graphite-scop-detection.c (working copy) @@ -21,13 +21,15 @@ #include "config.h" -#ifdef HAVE_cloog +#ifdef HAVE_isl #include <isl/set.h> #include <isl/map.h> #include <isl/union_map.h> +#ifdef HAVE_cloog #include <cloog/cloog.h> #include <cloog/isl/domain.h> #endif +#endif #include "system.h" #include "coretypes.h" @@ -56,7 +58,7 @@ #include "tree-ssa-propagate.h" #include "cp/cp-tree.h" -#ifdef HAVE_cloog +#ifdef HAVE_isl #include "graphite-poly.h" #include "graphite-scop-detection.h" Index: gcc/graphite-sese-to-poly.c =================================================================== --- gcc/graphite-sese-to-poly.c (revision 214008) +++ gcc/graphite-sese-to-poly.c (working copy) @@ -20,7 +20,7 @@ #include "config.h" -#ifdef HAVE_cloog +#ifdef HAVE_isl #include <isl/set.h> #include <isl/map.h> #include <isl/union_map.h> @@ -38,10 +38,12 @@ #if defined(__cplusplus) } #endif +#ifdef HAVE_cloog #include <cloog/cloog.h> #include <cloog/cloog.h> #include <cloog/isl/domain.h> #endif +#endif #include "system.h" #include "coretypes.h" @@ -74,7 +76,7 @@ #include "sese.h" #include "tree-ssa-propagate.h" -#ifdef HAVE_cloog +#ifdef HAVE_isl #include "expr.h" #include "graphite-poly.h" #include "graphite-sese-to-poly.h" Index: gcc/graphite.c =================================================================== --- gcc/graphite.c (revision 214008) +++ gcc/graphite.c (working copy) @@ -34,15 +34,17 @@ #include "config.h" -#ifdef HAVE_cloog +#ifdef HAVE_isl #include <isl/set.h> #include <isl/map.h> #include <isl/options.h> #include <isl/union_map.h> +#ifdef HAVE_cloog #include <cloog/cloog.h> #include <cloog/isl/domain.h> #include <cloog/isl/cloog.h> #endif +#endif #include "system.h" #include "coretypes.h" @@ -68,16 +70,19 @@ #include "tree-pass.h" #include "tree-cfgcleanup.h" -#ifdef HAVE_cloog +#ifdef HAVE_isl #include "graphite-poly.h" #include "graphite-scop-detection.h" -#include "graphite-clast-to-gimple.h" #include "graphite-isl-ast-to-gimple.h" #include "graphite-sese-to-poly.h" #include "graphite-htab.h" +#ifdef HAVE_cloog +#include "graphite-clast-to-gimple.h" + CloogState *cloog_state; +#endif /* Print global statistics to FILE. */ @@ -228,7 +233,9 @@ recompute_all_dominators (); initialize_original_copy_tables (); +#ifdef HAVE_cloog cloog_state = cloog_isl_state_malloc (ctx); +#endif if (dump_file && dump_flags) dump_function_to_file (current_function_decl, dump_file, dump_flags); @@ -251,7 +258,9 @@ tree_estimate_probability (); } +#ifdef HAVE_cloog cloog_state_free (cloog_state); +#endif free_original_copy_tables (); if (dump_file && dump_flags) @@ -292,12 +301,23 @@ } bb_pbb_htab_type bb_pbb_mapping (10); + +#ifndef HAVE_cloog + if(flag_graphite_code_gen == FGRAPHITE_CODE_GEN_CLOOG) + { + flag_graphite_code_gen = FGRAPHITE_CODE_GEN_ISL; + printf ("The CLooG code generator cannot be used (CLooG is not " + "available). The ISL code generator was chosen.\n"); + } +#endif + FOR_EACH_VEC_ELT (scops, i, scop) if (dbg_cnt (graphite_scop)) { scop->ctx = ctx; build_poly_scop (scop); +#ifdef HAVE_cloog if (POLY_SCOP_P (scop) && apply_poly_transforms (scop) && (((flag_graphite_code_gen == FGRAPHITE_CODE_GEN_ISL) @@ -305,6 +325,13 @@ || ((flag_graphite_code_gen == FGRAPHITE_CODE_GEN_CLOOG) && graphite_regenerate_ast_cloog (scop, &bb_pbb_mapping)))) need_cfg_cleanup_p = true; +#else + if (POLY_SCOP_P (scop) + && apply_poly_transforms (scop) + && graphite_regenerate_ast_isl (scop)) + need_cfg_cleanup_p = true; +#endif + } free_scops (scops); @@ -313,12 +340,12 @@ isl_ctx_free (ctx); } -#else /* If Cloog is not available: #ifndef HAVE_cloog. */ +#else /* If ISL is not available: #ifndef HAVE_isl. */ static void graphite_transform_loops (void) { - sorry ("Graphite loop optimizations cannot be used"); + sorry ("Graphite loop optimizations cannot be used (ISL is not available)."); } #endif Index: gcc/toplev.c =================================================================== --- gcc/toplev.c (revision 214008) +++ gcc/toplev.c (working copy) @@ -1275,15 +1275,15 @@ else aux_base_name = "gccaux"; -#ifndef HAVE_cloog +#ifndef HAVE_isl if (flag_graphite || flag_graphite_identity || flag_loop_block || flag_loop_interchange || flag_loop_strip_mine || flag_loop_parallelize_all) - sorry ("Graphite loop optimizations cannot be used (-fgraphite, " - "-fgraphite-identity, -floop-block, " + sorry ("Graphite loop optimizations cannot be used (ISL is not available)" + "(-fgraphite, -fgraphite-identity, -floop-block, " "-floop-interchange, -floop-strip-mine, -floop-parallelize-all, " "and -ftree-loop-linear)"); #endif [-- Attachment #5: patch1.txt --] [-- Type: text/plain, Size: 565 bytes --] Index: gcc/common.opt =================================================================== --- gcc/common.opt (revision 214000) +++ gcc/common.opt (working copy) @@ -1268,7 +1268,7 @@ Enable Graphite Identity transformation fgraphite-code-generator= -Common Report RejectNegative Joined Optimization Enum(fgraphite_generator) Var(flag_graphite_code_gen) Init(FGRAPHITE_CODE_GEN_CLOOG) +Common Report RejectNegative Joined Optimization Enum(fgraphite_generator) Var(flag_graphite_code_gen) Init(FGRAPHITE_CODE_GEN_ISL) Choose code generator of Graphite Enum ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [GSoC] Elimination of CLooG library installation dependency 2014-08-15 11:13 ` Roman Gareev @ 2014-08-15 11:45 ` Richard Biener 2014-08-16 5:28 ` Roman Gareev 2014-08-18 13:00 ` Richard Biener 1 sibling, 1 reply; 30+ messages in thread From: Richard Biener @ 2014-08-15 11:45 UTC (permalink / raw) To: Roman Gareev; +Cc: Tobias Grosser, Mircea Namolaru, GCC Patches On Fri, Aug 15, 2014 at 1:13 PM, Roman Gareev <gareevroman@gmail.com> wrote: >> I've attached the patch, which should eliminate CLooG library >> installation dependency from GCC. The CLooG AST generator is still the >> main code generator, but the isl ast generator will be chosen in case >> of nonavailability of CLooG library. >> >> However, I've found out a problem. Almost all the functions of the ISL >> cannot be used without installed CLooG. (I get errors which contain >> “undefined reference to...”). Maybe I missed something. What do you >> think about this? > > I’ve attached a patch, which contains mentioned changes and doesn’t > cause the error. I want to commit it in coming days. What do you think > about it? > Maybe we should make the ISL AST generator to be the main code > generator of Graphite (the patch1 implements this). What do you think > about it? We definitely should do that (and rip out the cloog code after a while). Richard. > > -- > Cheers, Roman Gareev. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [GSoC] Elimination of CLooG library installation dependency 2014-08-15 11:45 ` Richard Biener @ 2014-08-16 5:28 ` Roman Gareev 2014-08-16 10:40 ` Tobias Grosser 0 siblings, 1 reply; 30+ messages in thread From: Roman Gareev @ 2014-08-16 5:28 UTC (permalink / raw) To: Richard Biener; +Cc: Tobias Grosser, Mircea Namolaru, gcc-patches [-- Attachment #1: Type: text/plain, Size: 1302 bytes --] Richard, could you please review these patches? We would be very glad for your comments. P.S: I’ve attached an improved ChangeLog_entry. 2014-08-15 17:44 GMT+06:00 Richard Biener <richard.guenther@gmail.com>: > On Fri, Aug 15, 2014 at 1:13 PM, Roman Gareev <gareevroman@gmail.com> wrote: >>> I've attached the patch, which should eliminate CLooG library >>> installation dependency from GCC. The CLooG AST generator is still the >>> main code generator, but the isl ast generator will be chosen in case >>> of nonavailability of CLooG library. >>> >>> However, I've found out a problem. Almost all the functions of the ISL >>> cannot be used without installed CLooG. (I get errors which contain >>> “undefined reference to...”). Maybe I missed something. What do you >>> think about this? >> >> I’ve attached a patch, which contains mentioned changes and doesn’t >> cause the error. I want to commit it in coming days. What do you think >> about it? >> Maybe we should make the ISL AST generator to be the main code >> generator of Graphite (the patch1 implements this). What do you think >> about it? > > We definitely should do that (and rip out the cloog code after a while). > > Richard. -- Cheers, Roman Gareev. [-- Attachment #2: ChangeLog_entry.txt --] [-- Type: text/plain, Size: 925 bytes --] 2014-08-15 Roman Gareev <gareevroman@gmail.com> * configure.ac: Eliminate ClooG installation dependency. * configure: Regenerate. * Makefile.tpl: Add definition of ISLLIBS and HOST_ISLLIBS. * Makefile.in: Regenerate. [config/] * cloog.m4: Remove the path to isllibs from clooglibs. * isl.m4: Add paths to islinc, isllibs. [gcc/] * Makefile.in: Add definition of ISLLIBS, HOST_ISLLIBS. * config.in: Add undef of HAVE_isl. * configure: Regenerate. * configure.ac: Add definition of HAVE_isl. * graphite-blocking.c: Add checking of HAVE_isl. * graphite-dependences.c: Likewise. * graphite-interchange.c: Likewise. * graphite-isl-ast-to-gimple.c: Likewise. * graphite-optimize-isl.c: Likewise. * graphite-poly.c: Likewise. * graphite-scop-detection.c: Likewise. * graphite-sese-to-poly.c: Likewise. * graphite.c: Likewise. * toplev.c: Replace the checking of HAVE_cloog with the checking of HAVE_isl. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [GSoC] Elimination of CLooG library installation dependency 2014-08-16 5:28 ` Roman Gareev @ 2014-08-16 10:40 ` Tobias Grosser 0 siblings, 0 replies; 30+ messages in thread From: Tobias Grosser @ 2014-08-16 10:40 UTC (permalink / raw) To: Roman Gareev, Richard Biener; +Cc: Mircea Namolaru, gcc-patches On 16/08/2014 13:28, Roman Gareev wrote: > Richard, could you please review these patches? We would be very glad > for your comments. > > P.S: IÂ’ve attached an improved ChangeLog_entry. The patch and changelog looks good to me, but we still need a non-graphite reviewer oking the changes. Tobias ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [GSoC] Elimination of CLooG library installation dependency 2014-08-15 11:13 ` Roman Gareev 2014-08-15 11:45 ` Richard Biener @ 2014-08-18 13:00 ` Richard Biener 2014-08-18 15:22 ` Roman Gareev 1 sibling, 1 reply; 30+ messages in thread From: Richard Biener @ 2014-08-18 13:00 UTC (permalink / raw) To: Roman Gareev; +Cc: Tobias Grosser, Mircea Namolaru, GCC Patches On Fri, Aug 15, 2014 at 1:13 PM, Roman Gareev <gareevroman@gmail.com> wrote: >> I've attached the patch, which should eliminate CLooG library >> installation dependency from GCC. The CLooG AST generator is still the >> main code generator, but the isl ast generator will be chosen in case >> of nonavailability of CLooG library. >> >> However, I've found out a problem. Almost all the functions of the ISL >> cannot be used without installed CLooG. (I get errors which contain >> “undefined reference to...”). Maybe I missed something. What do you >> think about this? > > I’ve attached a patch, which contains mentioned changes and doesn’t > cause the error. I want to commit it in coming days. What do you think > about it? This patch is ok. I assume you have tested compiling with/without cloog and isl. > Maybe we should make the ISL AST generator to be the main code > generator of Graphite (the patch1 implements this). What do you think > about it? This patch is also ok if you and Tobias think it is ready for wider testing. I propose to remove the cloog path at latest when we enter stage3. Thanks, Richard. > > -- > Cheers, Roman Gareev. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [GSoC] Elimination of CLooG library installation dependency 2014-08-18 13:00 ` Richard Biener @ 2014-08-18 15:22 ` Roman Gareev 2014-08-20 3:28 ` Bin.Cheng 0 siblings, 1 reply; 30+ messages in thread From: Roman Gareev @ 2014-08-18 15:22 UTC (permalink / raw) To: Richard Biener; +Cc: Tobias Grosser, Mircea Namolaru, gcc-patches > This patch is ok. I assume you have tested compiling with/without cloog > and isl. Yes, I’ve tested compiling with/without cloog and isl. Thank you very much for review! -- Cheers, Roman Gareev. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [GSoC] Elimination of CLooG library installation dependency 2014-08-18 15:22 ` Roman Gareev @ 2014-08-20 3:28 ` Bin.Cheng 2014-08-20 5:24 ` Roman Gareev 0 siblings, 1 reply; 30+ messages in thread From: Bin.Cheng @ 2014-08-20 3:28 UTC (permalink / raw) To: Roman Gareev Cc: Richard Biener, Tobias Grosser, Mircea Namolaru, gcc-patches List I suspect this causes arm/aarch64 native bootstrap failure with below messages. aarch64-none-linux-gnu-g++ -c -g -O2 -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc/. -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc/../include -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc/../libcpp/include -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/workdir/aarch64-none-linux-gnu/sysroot//usr/include -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/workdir/aarch64-none-linux-gnu/sysroot//usr/include -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc/../libdecnumber -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc/../libbacktrace -DCLOOG_INT_GMP -o graphite.o -MT graphite.o -MMD -MP -MF ./.deps/graphite.TPo /projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc/graphite.c /projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc/graphite.c:38:21: fatal error: isl/set.h: No such file or directory compilation terminated. make[1]: *** [graphite.o] Error 1 make[1]: Leaving directory `/arm/scratch/pdtltest/bld-temporary/builds/fsf-trunk/502/workdir/aarch64-none-linux-gnu/obj/build-gcc/gcc' make: *** [all-gcc] Error 2 Thanks, bin On Mon, Aug 18, 2014 at 11:22 PM, Roman Gareev <gareevroman@gmail.com> wrote: >> This patch is ok. I assume you have tested compiling with/without cloog >> and isl. > > Yes, I've tested compiling with/without cloog and isl. Thank you very > much for review! > > -- > Cheers, Roman Gareev. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [GSoC] Elimination of CLooG library installation dependency 2014-08-20 3:28 ` Bin.Cheng @ 2014-08-20 5:24 ` Roman Gareev 2014-08-20 5:47 ` Bin.Cheng 0 siblings, 1 reply; 30+ messages in thread From: Roman Gareev @ 2014-08-20 5:24 UTC (permalink / raw) To: amker.cheng; +Cc: Richard Biener, Tobias Grosser, Mircea Namolaru, gcc-patches Which configure options do you use? Have you tried to bootstrap r214105 with same configure options? Have you tried to manually export the path to isl to LD_RUN_PATH? (You’ve probably tried. I just want to make sure.) 2014-08-20 9:28 GMT+06:00 Bin.Cheng <amker.cheng@gmail.com>: > I suspect this causes arm/aarch64 native bootstrap failure with below messages. > > aarch64-none-linux-gnu-g++ -c -g -O2 -DIN_GCC -fno-exceptions > -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing > -Wwrite-strings -Wcast-qual -Wmissing-format-attribute > -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros > -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. > -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc > -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc/. > -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc/../include > -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc/../libcpp/include > -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/workdir/aarch64-none-linux-gnu/sysroot//usr/include > -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/workdir/aarch64-none-linux-gnu/sysroot//usr/include > -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc/../libdecnumber > -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc/../libdecnumber/dpd > -I../libdecnumber > -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc/../libbacktrace > -DCLOOG_INT_GMP -o graphite.o -MT graphite.o -MMD -MP -MF > ./.deps/graphite.TPo > /projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc/graphite.c > /projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc/graphite.c:38:21: > fatal error: isl/set.h: No such file or directory > compilation terminated. > make[1]: *** [graphite.o] Error 1 > make[1]: Leaving directory > `/arm/scratch/pdtltest/bld-temporary/builds/fsf-trunk/502/workdir/aarch64-none-linux-gnu/obj/build-gcc/gcc' > make: *** [all-gcc] Error 2 > > Thanks, > bin -- Cheers, Roman Gareev. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [GSoC] Elimination of CLooG library installation dependency 2014-08-20 5:24 ` Roman Gareev @ 2014-08-20 5:47 ` Bin.Cheng 2014-08-21 5:15 ` Bin.Cheng 0 siblings, 1 reply; 30+ messages in thread From: Bin.Cheng @ 2014-08-20 5:47 UTC (permalink / raw) To: Roman Gareev Cc: Richard Biener, Tobias Grosser, Mircea Namolaru, gcc-patches List On Wed, Aug 20, 2014 at 1:24 PM, Roman Gareev <gareevroman@gmail.com> wrote: > Which configure options do you use? Have you tried to bootstrap > r214105 with same configure options? > Have you tried to manually export the path to isl to LD_RUN_PATH? > (You've probably tried. I just want to make sure.) I can't access the build bot right now, so haven't tried other options yet. The latest good I got build was against r213896. Thanks, bin > > > 2014-08-20 9:28 GMT+06:00 Bin.Cheng <amker.cheng@gmail.com>: >> I suspect this causes arm/aarch64 native bootstrap failure with below messages. >> >> aarch64-none-linux-gnu-g++ -c -g -O2 -DIN_GCC -fno-exceptions >> -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing >> -Wwrite-strings -Wcast-qual -Wmissing-format-attribute >> -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros >> -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. >> -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc >> -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc/. >> -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc/../include >> -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc/../libcpp/include >> -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/workdir/aarch64-none-linux-gnu/sysroot//usr/include >> -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/workdir/aarch64-none-linux-gnu/sysroot//usr/include >> -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc/../libdecnumber >> -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc/../libdecnumber/dpd >> -I../libdecnumber >> -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc/../libbacktrace >> -DCLOOG_INT_GMP -o graphite.o -MT graphite.o -MMD -MP -MF >> ./.deps/graphite.TPo >> /projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc/graphite.c >> /projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc/graphite.c:38:21: >> fatal error: isl/set.h: No such file or directory >> compilation terminated. >> make[1]: *** [graphite.o] Error 1 >> make[1]: Leaving directory >> `/arm/scratch/pdtltest/bld-temporary/builds/fsf-trunk/502/workdir/aarch64-none-linux-gnu/obj/build-gcc/gcc' >> make: *** [all-gcc] Error 2 >> >> Thanks, >> bin > > -- > Cheers, Roman Gareev. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [GSoC] Elimination of CLooG library installation dependency 2014-08-20 5:47 ` Bin.Cheng @ 2014-08-21 5:15 ` Bin.Cheng 0 siblings, 0 replies; 30+ messages in thread From: Bin.Cheng @ 2014-08-21 5:15 UTC (permalink / raw) To: Roman Gareev Cc: Richard Biener, Tobias Grosser, Mircea Namolaru, gcc-patches List I think it's a issue in isl library check for (Canadian) cross_compiling. Will send a patch soon. Thanks, bin On Wed, Aug 20, 2014 at 1:47 PM, Bin.Cheng <amker.cheng@gmail.com> wrote: > On Wed, Aug 20, 2014 at 1:24 PM, Roman Gareev <gareevroman@gmail.com> wrote: >> Which configure options do you use? Have you tried to bootstrap >> r214105 with same configure options? >> Have you tried to manually export the path to isl to LD_RUN_PATH? >> (You've probably tried. I just want to make sure.) > > I can't access the build bot right now, so haven't tried other options > yet. The latest good I got build was against r213896. > > Thanks, > bin >> >> >> 2014-08-20 9:28 GMT+06:00 Bin.Cheng <amker.cheng@gmail.com>: >>> I suspect this causes arm/aarch64 native bootstrap failure with below messages. >>> >>> aarch64-none-linux-gnu-g++ -c -g -O2 -DIN_GCC -fno-exceptions >>> -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing >>> -Wwrite-strings -Wcast-qual -Wmissing-format-attribute >>> -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros >>> -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. >>> -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc >>> -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc/. >>> -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc/../include >>> -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc/../libcpp/include >>> -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/workdir/aarch64-none-linux-gnu/sysroot//usr/include >>> -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/workdir/aarch64-none-linux-gnu/sysroot//usr/include >>> -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc/../libdecnumber >>> -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc/../libdecnumber/dpd >>> -I../libdecnumber >>> -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc/../libbacktrace >>> -DCLOOG_INT_GMP -o graphite.o -MT graphite.o -MMD -MP -MF >>> ./.deps/graphite.TPo >>> /projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc/graphite.c >>> /projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc/graphite.c:38:21: >>> fatal error: isl/set.h: No such file or directory >>> compilation terminated. >>> make[1]: *** [graphite.o] Error 1 >>> make[1]: Leaving directory >>> `/arm/scratch/pdtltest/bld-temporary/builds/fsf-trunk/502/workdir/aarch64-none-linux-gnu/obj/build-gcc/gcc' >>> make: *** [all-gcc] Error 2 >>> >>> Thanks, >>> bin >> >> -- >> Cheers, Roman Gareev. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [GSoC] Elimination of CLooG library installation dependency
@ 2014-08-23 16:48 Dominique d'Humières
2014-08-24 7:00 ` Roman Gareev
0 siblings, 1 reply; 30+ messages in thread
From: Dominique d'Humières @ 2014-08-23 16:48 UTC (permalink / raw)
To: gareevroman
Cc: tobias, richard.guenther, mircea.namolaru,
Dominique d'Humieres, gcc-patches
I see two regressions after r214069 on x86_64-apple-darwin13 for both -m32 and -m64:
(1) FAIL: gcc.dg/graphite/vect-pr43423.c scan-tree-dump-times vect "vectorized 2 loops" 1
before I saw
[Book15] f90/bug% grep vectorized vect-pr43423.c.114t.vect
/opt/gcc/p_work/gcc/testsuite/gcc.dg/graphite/vect-pr43423.c:14:17: note: === vect_mark_stmts_to_be_vectorized ===
/opt/gcc/p_work/gcc/testsuite/gcc.dg/graphite/vect-pr43423.c:14:17: note: loop vectorized
/opt/gcc/p_work/gcc/testsuite/gcc.dg/graphite/vect-pr43423.c:12:17: note: === vect_mark_stmts_to_be_vectorized ===
/opt/gcc/p_work/gcc/testsuite/gcc.dg/graphite/vect-pr43423.c:12:17: note: loop vectorized
/opt/gcc/p_work/gcc/testsuite/gcc.dg/graphite/vect-pr43423.c:6:6: note: vectorized 2 loops in function.
after I see
[Book15] f90/bug% grep vectorized vect-pr43423.c.115t.vect /opt/gcc/p_work/gcc/testsuite/gcc.dg/graphite/vect-pr43423.c:14:17: note: not vectorized: not suitable for gather load _55 = a[_56];
/opt/gcc/p_work/gcc/testsuite/gcc.dg/graphite/vect-pr43423.c:12:17: note: not vectorized: not suitable for gather load _36 = a[_37];
/opt/gcc/p_work/gcc/testsuite/gcc.dg/graphite/vect-pr43423.c:6:6: note: vectorized 0 loops in function.
(2) FAIL: gfortran.dg/graphite/pr42393.f90 -O (internal compiler error)
FAIL: gfortran.dg/graphite/pr42393.f90 -O (test for excess errors)
The backtrace is
* thread #1: tid = 0x13bd91f, 0x00007fff8621aca0 libsystem_malloc.dylib`tiny_malloc_from_free_list + 12, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=2, address=0x7fff5bc00ff8)
frame #0: 0x00007fff8621aca0 libsystem_malloc.dylib`tiny_malloc_from_free_list + 12
libsystem_malloc.dylib`tiny_malloc_from_free_list + 12:
-> 0x7fff8621aca0: pushq %rbx
0x7fff8621aca1: pushq %rax
0x7fff8621aca2: movl %edx, %r12d
0x7fff8621aca5: movq %rsi, %r14
(lldb) bt
* thread #1: tid = 0x13bd91f, 0x00007fff8621aca0 libsystem_malloc.dylib`tiny_malloc_from_free_list + 12, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=2, address=0x7fff5bc00ff8)
* frame #0: 0x00007fff8621aca0 libsystem_malloc.dylib`tiny_malloc_from_free_list + 12
frame #1: 0x00007fff8621b3c3 libsystem_malloc.dylib`szone_malloc_should_clear + 320
frame #2: 0x00007fff8621d868 libsystem_malloc.dylib`malloc_zone_malloc + 71
frame #3: 0x00007fff8621e27c libsystem_malloc.dylib`malloc + 42
frame #4: 0x0000000141dbdc79 libgmp.10.dylib`__gmp_default_allocate + 9
frame #5: 0x0000000141dd0148 libgmp.10.dylib`__gmpz_init + 24
frame #6: 0x0000000141c180ef libisl.10.dylib`isl_basic_map_normalize_constraints + 47
frame #7: 0x0000000141c18f04 libisl.10.dylib`isl_basic_map_simplify + 68
frame #8: 0x0000000141c2509b libisl.10.dylib`isl_basic_set_preimage + 619
frame #9: 0x0000000141c4e146 libisl.10.dylib`isl_basic_set_sample_with_cone + 150
frame #10: 0x0000000141c4ea88 libisl.10.dylib`basic_set_sample + 744
frame #11: 0x0000000141c4e849 libisl.10.dylib`basic_set_sample + 169
frame #12: 0x0000000141c09978 libisl.10.dylib`isl_basic_map_is_empty + 136
frame #13: 0x0000000141bb2870 libisl.10.dylib`domain_follows_at_depth + 112
frame #14: 0x0000000141c7cdba libisl.10.dylib`isl_tarjan_components + 154
getting to the ICE take ~19s compared to less than a second before r214069.
Dominique
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: [GSoC] Elimination of CLooG library installation dependency 2014-08-23 16:48 Dominique d'Humières @ 2014-08-24 7:00 ` Roman Gareev 0 siblings, 0 replies; 30+ messages in thread From: Roman Gareev @ 2014-08-24 7:00 UTC (permalink / raw) To: Dominique Dhumieres Cc: Tobias Grosser, Richard Biener, Mircea Namolaru, gcc-patches Thank you for the report! > (1) FAIL: gcc.dg/graphite/vect-pr43423.c scan-tree-dump-times vect "vectorized 2 loops" 1 > > before I saw > > [Book15] f90/bug% grep vectorized vect-pr43423.c.114t.vect > /opt/gcc/p_work/gcc/testsuite/gcc.dg/graphite/vect-pr43423.c:14:17: note: === vect_mark_stmts_to_be_vectorized === > /opt/gcc/p_work/gcc/testsuite/gcc.dg/graphite/vect-pr43423.c:14:17: note: loop vectorized > /opt/gcc/p_work/gcc/testsuite/gcc.dg/graphite/vect-pr43423.c:12:17: note: === vect_mark_stmts_to_be_vectorized === > /opt/gcc/p_work/gcc/testsuite/gcc.dg/graphite/vect-pr43423.c:12:17: note: loop vectorized > /opt/gcc/p_work/gcc/testsuite/gcc.dg/graphite/vect-pr43423.c:6:6: note: vectorized 2 loops in function. > > after I see > > [Book15] f90/bug% grep vectorized vect-pr43423.c.115t.vect /opt/gcc/p_work/gcc/testsuite/gcc.dg/graphite/vect-pr43423.c:14:17: note: not vectorized: not suitable for gather load _55 = a[_56]; > /opt/gcc/p_work/gcc/testsuite/gcc.dg/graphite/vect-pr43423.c:12:17: note: not vectorized: not suitable for gather load _36 = a[_37]; > /opt/gcc/p_work/gcc/testsuite/gcc.dg/graphite/vect-pr43423.c:6:6: note: vectorized 0 loops in function. We’ve already met with this problem. https://gcc.gnu.org/ml/gcc-patches/2014-08/msg00118.html https://gcc.gnu.org/ml/gcc-patches/2014-08/msg00155.html https://gcc.gnu.org/ml/gcc-patches/2014-08/msg00173.html In our opinion, it requires help of the vectorizer people. Maybe it’ll disappear by itself, when the computation of types is finished. > (2) FAIL: gfortran.dg/graphite/pr42393.f90 -O (internal compiler error) > FAIL: gfortran.dg/graphite/pr42393.f90 -O (test for excess errors) > > The backtrace is > > * thread #1: tid = 0x13bd91f, 0x00007fff8621aca0 libsystem_malloc.dylib`tiny_malloc_from_free_list + 12, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=2, address=0x7fff5bc00ff8) > frame #0: 0x00007fff8621aca0 libsystem_malloc.dylib`tiny_malloc_from_free_list + 12 > libsystem_malloc.dylib`tiny_malloc_from_free_list + 12: > -> 0x7fff8621aca0: pushq %rbx > 0x7fff8621aca1: pushq %rax > 0x7fff8621aca2: movl %edx, %r12d > 0x7fff8621aca5: movq %rsi, %r14 > (lldb) bt > * thread #1: tid = 0x13bd91f, 0x00007fff8621aca0 libsystem_malloc.dylib`tiny_malloc_from_free_list + 12, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=2, address=0x7fff5bc00ff8) > * frame #0: 0x00007fff8621aca0 libsystem_malloc.dylib`tiny_malloc_from_free_list + 12 > frame #1: 0x00007fff8621b3c3 libsystem_malloc.dylib`szone_malloc_should_clear + 320 > frame #2: 0x00007fff8621d868 libsystem_malloc.dylib`malloc_zone_malloc + 71 > frame #3: 0x00007fff8621e27c libsystem_malloc.dylib`malloc + 42 > frame #4: 0x0000000141dbdc79 libgmp.10.dylib`__gmp_default_allocate + 9 > frame #5: 0x0000000141dd0148 libgmp.10.dylib`__gmpz_init + 24 > frame #6: 0x0000000141c180ef libisl.10.dylib`isl_basic_map_normalize_constraints + 47 > frame #7: 0x0000000141c18f04 libisl.10.dylib`isl_basic_map_simplify + 68 > frame #8: 0x0000000141c2509b libisl.10.dylib`isl_basic_set_preimage + 619 > frame #9: 0x0000000141c4e146 libisl.10.dylib`isl_basic_set_sample_with_cone + 150 > frame #10: 0x0000000141c4ea88 libisl.10.dylib`basic_set_sample + 744 > frame #11: 0x0000000141c4e849 libisl.10.dylib`basic_set_sample + 169 > frame #12: 0x0000000141c09978 libisl.10.dylib`isl_basic_map_is_empty + 136 > frame #13: 0x0000000141bb2870 libisl.10.dylib`domain_follows_at_depth + 112 > frame #14: 0x0000000141c7cdba libisl.10.dylib`isl_tarjan_components + 154 > > getting to the ICE take ~19s compared to less than a second before r214069. This is a bug in ISL. They’ll fix it in a new version of ISL. https://groups.google.com/forum/#!topic/isl-development/SeNZf5IA-Lk -- Cheers, Roman Gareev. ^ permalink raw reply [flat|nested] 30+ messages in thread
end of thread, other threads:[~2014-08-24 7:00 UTC | newest] Thread overview: 30+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-08-06 15:22 [GSoC] Elimination of CLooG library installation dependency Roman Gareev 2014-08-06 15:48 ` Tobias Grosser 2014-08-07 13:18 ` Roman Gareev 2014-08-07 13:35 ` Tobias Grosser 2014-08-08 13:11 ` Roman Gareev 2014-08-08 13:16 ` Tobias Grosser 2014-08-09 7:42 ` Roman Gareev 2014-08-09 7:52 ` Tobias Grosser 2014-08-09 10:05 ` Roman Gareev 2014-08-11 6:26 ` Tobias Grosser 2014-08-11 7:11 ` Roman Gareev 2014-08-11 7:27 ` Tobias Grosser 2014-08-11 14:20 ` Roman Gareev 2014-08-13 8:07 ` Roman Gareev 2014-08-13 8:56 ` Tobias Grosser 2014-08-13 11:48 ` Roman Gareev 2014-08-13 9:55 ` Richard Biener 2014-08-13 11:49 ` Roman Gareev 2014-08-15 11:13 ` Roman Gareev 2014-08-15 11:45 ` Richard Biener 2014-08-16 5:28 ` Roman Gareev 2014-08-16 10:40 ` Tobias Grosser 2014-08-18 13:00 ` Richard Biener 2014-08-18 15:22 ` Roman Gareev 2014-08-20 3:28 ` Bin.Cheng 2014-08-20 5:24 ` Roman Gareev 2014-08-20 5:47 ` Bin.Cheng 2014-08-21 5:15 ` Bin.Cheng 2014-08-23 16:48 Dominique d'Humières 2014-08-24 7:00 ` Roman Gareev
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).