[PATCH 2/3] Fix include order to avoid failed compilation on CLOOG_ORG.

[PATCH 2/3] Fix include order to avoid failed compilation on CLOOG_ORG.

[Andreas Simbürger]

2010-08-11  Andreas Simbuerger  <simbuerg@fim.uni-passau.de>

	* graphite-poly.c: Change include order.
---
 gcc/ChangeLog.graphite |    4 ++++
 gcc/graphite-poly.c    |    2 +-
 2 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/gcc/ChangeLog.graphite b/gcc/ChangeLog.graphite
index 486cd37..54c33ef 100644
--- a/gcc/ChangeLog.graphite
+++ b/gcc/ChangeLog.graphite
@@ -1,5 +1,9 @@
 2010-08-11  Andreas Simbuerger  <simbuerg@fim.uni-passau.de>
 
+	* graphite-poly.c: Change include order.
+
+2010-08-11  Andreas Simbuerger  <simbuerg@fim.uni-passau.de>
+
 	* graphite-cloog-compat.h (cloog_matrix_ncolumns): New.
 	(cloog_matrix_nrows): New.
 
diff --git a/gcc/graphite-poly.c b/gcc/graphite-poly.c
index c1ac69e..24911d6 100644
--- a/gcc/graphite-poly.c
+++ b/gcc/graphite-poly.c
@@ -44,7 +44,6 @@ along with GCC; see the file COPYING3.  If not see
 #include "pointer-set.h"
 #include "gimple.h"
 #include "params.h"
-#include "graphite-cloog-util.h"
 
 #ifdef HAVE_cloog
 #include "ppl_c.h"
@@ -53,6 +52,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "graphite.h"
 #include "graphite-poly.h"
 #include "graphite-dependences.h"
+#include "graphite-cloog-util.h"
 
 /* Return the maximal loop depth in SCOP.  */
 
-- 
1.7.2

[PATCH 0/3] Configure support for official CLooG versions.

[Andreas Simbürger]

Hi,

this patch series adds configure support for upstream CLooG versions.
The official CLooG is able to use three different backends during
code generation. An ISL backend, a PPL backend and a PolyLib backend.

Furthermore the old CLooG-PPL (Legacy) fork used by graphite at the
moment is still supported.
While checking for the used CLooG version we check in the following
order: PPL (Legacy) > ISL > PPL > PolyLib.

This means, we don't change the default behavior of CLooG yet.
As we still need to discuss some aspects of providing information 
with upstream it is necessary to disable the cloog version check
(--disable-cloog-version-check) to use one of the upstream
CLooG versions for now.

After successfully completing all test suites we want to switch
to CLooG-ISL and abandon the legacy CLooG-PPL.

Andreas

Andreas Simbürger (3):
  Add necessary accessors for CloogMatrix (CLOOG_ORG).
  Fix include order to avoid failed compilation on CLOOG_ORG.
  Support official CLooG.org versions.

 configure                   |  156 +++++++++++++++++++++++++++++++++++++------
 configure.ac                |   90 ++++++++++++++++++------
 gcc/ChangeLog.graphite      |   14 ++++
 gcc/graphite-cloog-compat.h |   10 +++
 gcc/graphite-poly.c         |    2 +-
 5 files changed, 228 insertions(+), 44 deletions(-)

-- 
1.7.2

[PATCH 1/3] Add necessary accessors for CloogMatrix (CLOOG_ORG).

[Andreas Simbürger]

2010-08-11  Andreas Simbuerger  <simbuerg@fim.uni-passau.de>

	* graphite-cloog-compat.h (cloog_matrix_ncolumns): New.
	(cloog_matrix_nrows): New.
---
 gcc/ChangeLog.graphite      |    5 +++++
 gcc/graphite-cloog-compat.h |   10 ++++++++++
 2 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/gcc/ChangeLog.graphite b/gcc/ChangeLog.graphite
index 6805a5a..486cd37 100644
--- a/gcc/ChangeLog.graphite
+++ b/gcc/ChangeLog.graphite
@@ -1,3 +1,8 @@
+2010-08-11  Andreas Simbuerger  <simbuerg@fim.uni-passau.de>
+
+	* graphite-cloog-compat.h (cloog_matrix_ncolumns): New.
+	(cloog_matrix_nrows): New.
+
 2010-07-29  Sebastian Pop  <sebastian.pop@amd.com>
 
 	* gcc.dg/graphite/graphite.exp: Add compile rules for vect-* files.
diff --git a/gcc/graphite-cloog-compat.h b/gcc/graphite-cloog-compat.h
index 03fc124..7f2db71 100644
--- a/gcc/graphite-cloog-compat.h
+++ b/gcc/graphite-cloog-compat.h
@@ -261,5 +261,15 @@ cloog_block_list_set_block (CloogBlockList *bl, CloogBlock *block)
 {
   bl->block = block;
 }
+
+static inline int cloog_matrix_ncolumns (CloogMatrix * m)
+{
+  return m->NbColumns;
+}
+
+static inline int cloog_matrix_nrows (CloogMatrix * m)
+{
+   return m->NbRows;
+}
 #endif /* CLOOG_ORG  */
 #endif /* GRAPHITE_CLOOG_COMPAT_H  */
-- 
1.7.2

[PATCH 3/3] Support official CLooG.org versions.

[Andreas Simbürger]

2010-08-11  Andreas Simbuerger  <simbuerg@fim.uni-passau.de>

	* configure.ac: Support official CLooG.org versions.
	* configure: Regenerate.
---
 configure              |  156 +++++++++++++++++++++++++++++++++++++++++------
 configure.ac           |   90 +++++++++++++++++++++-------
 gcc/ChangeLog.graphite |    5 ++
 3 files changed, 208 insertions(+), 43 deletions(-)

diff --git a/configure b/configure
index 8edfde3..23b6cf1 100755
--- a/configure
+++ b/configure
@@ -5891,8 +5891,11 @@ fi
 
 
 # Check for CLOOG
-clooglibs=" -lcloog "
-clooginc=" -DCLOOG_PPL_BACKEND "
+
+clooglibs=
+clooginc=
+clooglegacyinc="-DCLOOG_PPL_BACKEND "
+cloogorginc="-DCLOOG_INT_GMP -DCLOOG_ORG "
 
 
 # Check whether --with-cloog was given.
@@ -5925,19 +5928,19 @@ case $with_cloog in
   "" | yes)
     ;;
   *)
-    clooglibs="-L$with_cloog/lib -lcloog"
-    clooginc="-I$with_cloog/include -DCLOOG_PPL_BACKEND "
+    clooglibs="-L$with_cloog/lib ${clooglibs} "
+    clooginc="-I$with_cloog/include ${clooginc} "
     ;;
 esac
 if test "x$with_cloog_include" != x; then
-  clooginc="-I$with_cloog_include -DCLOOG_PPL_BACKEND "
+  clooginc="-I$with_cloog_include ${clooginc}"
 fi
 if test "x$with_cloog_lib" != x; then
-  clooglibs="-L$with_cloog_lib -lcloog"
+  clooglibs="-L$with_cloog_lib ${clooglibs}"
 fi
 if test "x$with_cloog$with_cloog_include$with_cloog_lib" = x && test -d ${srcdir}/cloog; then
-  clooglibs='-L$$r/$(HOST_SUBDIR)/cloog/'"$lt_cv_objdir"' -lcloog '
-  clooginc='-I$$r/$(HOST_SUBDIR)/cloog/include -I$$s/cloog/include -DCLOOG_PPL_BACKEND '
+  clooglibs='-L$$r/$(HOST_SUBDIR)/cloog/'"$lt_cv_objdir"' ${clooglibs} '
+  clooginc='-I$$r/$(HOST_SUBDIR)/cloog/include -I$$s/cloog/include ${clooginc} '
   enable_cloog_version_check=no
 fi
 
@@ -5949,21 +5952,133 @@ else
 fi
 
 
-if test "x$with_cloog" != "xno" -a "${ENABLE_CLOOG_CHECK}" = "yes"; then
-  saved_CFLAGS="$CFLAGS"
-  CFLAGS="$CFLAGS $clooginc $gmpinc $pplinc"
-  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for version 0.15.5 (or later revision) of CLooG" >&5
-$as_echo_n "checking for version 0.15.5 (or later revision) of CLooG... " >&6; }
+if test "x$with_cloog" != "xno"; then
+  # Test for CLooG variant.
+  saved_cflags=$CFLAGS
+  saved_libs=$LIBS
+  saved_ldflags=$LDFLAGS
+  cloog_lib=
+  cloog_inc=
+
+
+  CFLAGS="${CFLAGS} ${gmpinc} ${pplinc} ${clooginc} ${cloogorginc} "
+  LDFLAGS="${LDFLAGS} ${clooglibs} "
+
+  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for CLooG's backend" >&5
+$as_echo_n "checking for CLooG's backend... " >&6; }
+  cloog_lib="-lcloog";
+  cloog_inc=$clooglegacyinc;
+  LIBS=$cloog_lib
+  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+#include <cloog/cloog.h>
+int
+main ()
+{
+cloog_version ()
+  ;
+  return 0;
+}
+_ACEOF
+if ac_fn_c_try_link "$LINENO"; then :
+  { $as_echo "$as_me:${as_lineno-$LINENO}: result: PPL (Legacy)" >&5
+$as_echo "PPL (Legacy)" >&6; }
+else
+
+  cloog_lib="-lcloog-isl";
+  cloog_inc=$cloogorginc;
+  LIBS=$cloog_lib;
+  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+#include <cloog/cloog.h>
+int
+main ()
+{
+cloog_version ()
+  ;
+  return 0;
+}
+_ACEOF
+if ac_fn_c_try_link "$LINENO"; then :
+  { $as_echo "$as_me:${as_lineno-$LINENO}: result: ISL" >&5
+$as_echo "ISL" >&6; }
+else
+
+  cloog_lib="-lcloog-ppl";
+  cloog_inc=$cloogorginc;
+  LIBS=$cloog_lib;
+  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+#include <cloog/cloog.h>
+int
+main ()
+{
+cloog_version ()
+  ;
+  return 0;
+}
+_ACEOF
+if ac_fn_c_try_link "$LINENO"; then :
+  { $as_echo "$as_me:${as_lineno-$LINENO}: result: PPL" >&5
+$as_echo "PPL" >&6; }
+else
+
+  cloog_lib="-lcloog-polylib";
+  cloog_inc=$cloogorginc;
+  LIBS=$cloog_lib;
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
 /* end confdefs.h.  */
+#include <cloog/cloog.h>
+int
+main ()
+{
+cloog_version ()
+  ;
+  return 0;
+}
+_ACEOF
+if ac_fn_c_try_link "$LINENO"; then :
+  { $as_echo "$as_me:${as_lineno-$LINENO}: result: PolyLib" >&5
+$as_echo "PolyLib" >&6; }
+else
+
+  { $as_echo "$as_me:${as_lineno-$LINENO}: result: none" >&5
+$as_echo "none" >&6; }
+fi
+rm -f core conftest.err conftest.$ac_objext \
+    conftest$ac_exeext conftest.$ac_ext
+fi
+rm -f core conftest.err conftest.$ac_objext \
+    conftest$ac_exeext conftest.$ac_ext
+fi
+rm -f core conftest.err conftest.$ac_objext \
+    conftest$ac_exeext conftest.$ac_ext
+fi
+rm -f core conftest.err conftest.$ac_objext \
+    conftest$ac_exeext conftest.$ac_ext
+
+  clooglibs=$clooglibs$cloog_lib
+  clooginc=$clooginc$cloog_inc
+  CFLAGS=$saved_cflags
+  LIBS=$saved_libs
+  LDFLAGS=$saved_ldflags
+
+  # Test for CLooG version
+  if test "${ENABLE_CLOOG_CHECK}" = "yes"; then
+    saved_CFLAGS="$CFLAGS"
+    CFLAGS="$CFLAGS $clooginc $gmpinc $pplinc"
+    { $as_echo "$as_me:${as_lineno-$LINENO}: checking for version 0.15.5 (or later revision) of CLooG" >&5
+$as_echo_n "checking for version 0.15.5 (or later revision) of CLooG... " >&6; }
+    cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
 #include "cloog/cloog.h"
 int
 main ()
 {
 
-  #if CLOOG_VERSION_MAJOR != 0 || CLOOG_VERSION_MINOR != 15 || CLOOG_VERSION_REVISION < 5
-  choke me
-  #endif
+    #if CLOOG_VERSION_MAJOR != 0 || CLOOG_VERSION_MINOR != 15 || CLOOG_VERSION_REVISION < 5
+    choke me
+    #endif
 
   ;
   return 0;
@@ -5977,9 +6092,9 @@ int
 main ()
 {
 
-  #if CLOOG_VERSION_MAJOR != 0 || CLOOG_VERSION_MINOR != 15 || CLOOG_VERSION_REVISION < 9
-  choke me
-  #endif
+    #if CLOOG_VERSION_MAJOR != 0 || CLOOG_VERSION_MINOR != 15 || CLOOG_VERSION_REVISION < 9
+    choke me
+    #endif
 
   ;
   return 0;
@@ -5998,7 +6113,8 @@ else
 $as_echo "no" >&6; }; clooglibs= ; clooginc=
 fi
 rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
-  CFLAGS="$saved_CFLAGS"
+    CFLAGS="$saved_CFLAGS"
+  fi
 fi
 
 # Flags needed for CLOOG
diff --git a/configure.ac b/configure.ac
index f78c527..4e7274e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1586,8 +1586,11 @@ AC_SUBST(pplinc)
 
 
 # Check for CLOOG
-clooglibs=" -lcloog "
-clooginc=" -DCLOOG_PPL_BACKEND "
+
+clooglibs=
+clooginc=
+clooglegacyinc="-DCLOOG_PPL_BACKEND "
+cloogorginc="-DCLOOG_INT_GMP -DCLOOG_ORG "
 
 AC_ARG_WITH(cloog, [  --with-cloog=PATH       Specify prefix directory for the installed CLooG-PPL package
                           Equivalent to --with-cloog-include=PATH/include
@@ -1607,19 +1610,19 @@ case $with_cloog in
   "" | yes)
     ;;
   *)
-    clooglibs="-L$with_cloog/lib -lcloog"
-    clooginc="-I$with_cloog/include -DCLOOG_PPL_BACKEND "
+    clooglibs="-L$with_cloog/lib ${clooglibs} "
+    clooginc="-I$with_cloog/include ${clooginc} "
     ;;
 esac
 if test "x$with_cloog_include" != x; then
-  clooginc="-I$with_cloog_include -DCLOOG_PPL_BACKEND "
+  clooginc="-I$with_cloog_include ${clooginc}"
 fi
 if test "x$with_cloog_lib" != x; then
-  clooglibs="-L$with_cloog_lib -lcloog"
+  clooglibs="-L$with_cloog_lib ${clooglibs}"
 fi
 if test "x$with_cloog$with_cloog_include$with_cloog_lib" = x && test -d ${srcdir}/cloog; then
-  clooglibs='-L$$r/$(HOST_SUBDIR)/cloog/'"$lt_cv_objdir"' -lcloog '
-  clooginc='-I$$r/$(HOST_SUBDIR)/cloog/include -I$$s/cloog/include -DCLOOG_PPL_BACKEND '
+  clooglibs='-L$$r/$(HOST_SUBDIR)/cloog/'"$lt_cv_objdir"' ${clooglibs} '
+  clooginc='-I$$r/$(HOST_SUBDIR)/cloog/include -I$$s/cloog/include ${clooginc} '
   enable_cloog_version_check=no
 fi
 
@@ -1628,21 +1631,62 @@ AC_ARG_ENABLE(cloog-version-check,
 ENABLE_CLOOG_CHECK=$enableval,
 ENABLE_CLOOG_CHECK=yes)
 
-if test "x$with_cloog" != "xno" -a "${ENABLE_CLOOG_CHECK}" = "yes"; then
-  saved_CFLAGS="$CFLAGS"
-  CFLAGS="$CFLAGS $clooginc $gmpinc $pplinc"
-  AC_MSG_CHECKING([for version 0.15.5 (or later revision) of CLooG])
-  AC_TRY_COMPILE([#include "cloog/cloog.h"],[
-  #if CLOOG_VERSION_MAJOR != 0 || CLOOG_VERSION_MINOR != 15 || CLOOG_VERSION_REVISION < 5
-  choke me
-  #endif
-  ], [AC_TRY_COMPILE([#include "cloog/cloog.h"],[
-  #if CLOOG_VERSION_MAJOR != 0 || CLOOG_VERSION_MINOR != 15 || CLOOG_VERSION_REVISION < 9
-  choke me
-  #endif
-  ], [AC_MSG_RESULT([yes])], [AC_MSG_RESULT([buggy but acceptable])])],
-  [AC_MSG_RESULT([no]); clooglibs= ; clooginc= ])
-  CFLAGS="$saved_CFLAGS"
+if test "x$with_cloog" != "xno"; then
+  # Test for CLooG variant.
+  saved_cflags=$CFLAGS
+  saved_libs=$LIBS
+  saved_ldflags=$LDFLAGS
+  cloog_lib=
+  cloog_inc=
+  m4_define([CLOOG_BACKEND_PROG],[AC_LANG_PROGRAM(
+    [#include <cloog/cloog.h>],
+    [cloog_version ()])])
+
+  CFLAGS="${CFLAGS} ${gmpinc} ${pplinc} ${clooginc} ${cloogorginc} "
+  LDFLAGS="${LDFLAGS} ${clooglibs} "
+
+  AC_MSG_CHECKING(for CLooG's backend)
+  cloog_lib="-lcloog";
+  cloog_inc=$clooglegacyinc;
+  LIBS=$cloog_lib
+  AC_LINK_IFELSE([CLOOG_BACKEND_PROG], [AC_MSG_RESULT([PPL (Legacy)])],[
+  cloog_lib="-lcloog-isl";
+  cloog_inc=$cloogorginc;
+  LIBS=$cloog_lib;
+  AC_LINK_IFELSE([CLOOG_BACKEND_PROG], [AC_MSG_RESULT([ISL])],[
+  cloog_lib="-lcloog-ppl";
+  cloog_inc=$cloogorginc;
+  LIBS=$cloog_lib;
+  AC_LINK_IFELSE([CLOOG_BACKEND_PROG], [AC_MSG_RESULT([PPL])],[
+  cloog_lib="-lcloog-polylib";
+  cloog_inc=$cloogorginc;
+  LIBS=$cloog_lib;
+  AC_LINK_IFELSE([CLOOG_BACKEND_PROG], [AC_MSG_RESULT([PolyLib])],[
+  AC_MSG_RESULT([none])])])])])
+
+  clooglibs=$clooglibs$cloog_lib
+  clooginc=$clooginc$cloog_inc
+  CFLAGS=$saved_cflags
+  LIBS=$saved_libs
+  LDFLAGS=$saved_ldflags
+
+  # Test for CLooG version
+  if test "${ENABLE_CLOOG_CHECK}" = "yes"; then
+    saved_CFLAGS="$CFLAGS"
+    CFLAGS="$CFLAGS $clooginc $gmpinc $pplinc"
+    AC_MSG_CHECKING([for version 0.15.5 (or later revision) of CLooG])
+    AC_TRY_COMPILE([#include "cloog/cloog.h"],[
+    #if CLOOG_VERSION_MAJOR != 0 || CLOOG_VERSION_MINOR != 15 || CLOOG_VERSION_REVISION < 5
+    choke me
+    #endif
+    ], [AC_TRY_COMPILE([#include "cloog/cloog.h"],[
+    #if CLOOG_VERSION_MAJOR != 0 || CLOOG_VERSION_MINOR != 15 || CLOOG_VERSION_REVISION < 9
+    choke me
+    #endif
+    ], [AC_MSG_RESULT([yes])], [AC_MSG_RESULT([buggy but acceptable])])],
+    [AC_MSG_RESULT([no]); clooglibs= ; clooginc= ])
+    CFLAGS="$saved_CFLAGS"
+  fi
 fi
 
 # Flags needed for CLOOG
diff --git a/gcc/ChangeLog.graphite b/gcc/ChangeLog.graphite
index 54c33ef..5eaa47c 100644
--- a/gcc/ChangeLog.graphite
+++ b/gcc/ChangeLog.graphite
@@ -1,5 +1,10 @@
 2010-08-11  Andreas Simbuerger  <simbuerg@fim.uni-passau.de>
 
+	* configure.ac: Support official CLooG.org versions.
+	* configure: Regenerate.
+
+2010-08-11  Andreas Simbuerger  <simbuerg@fim.uni-passau.de>
+
 	* graphite-poly.c: Change include order.
 
 2010-08-11  Andreas Simbuerger  <simbuerg@fim.uni-passau.de>
-- 
1.7.2

Re: [PATCH 0/3] Configure support for official CLooG versions.

[Sebastian Pop]

On Wed, Aug 11, 2010 at 13:30, Andreas Simbürger
<simbuerg@googlemail.com> wrote:
> Hi,
>
> this patch series adds configure support for upstream CLooG versions.
> The official CLooG is able to use three different backends during
> code generation. An ISL backend, a PPL backend and a PolyLib backend.
>
> Furthermore the old CLooG-PPL (Legacy) fork used by graphite at the
> moment is still supported.
> While checking for the used CLooG version we check in the following
> order: PPL (Legacy) > ISL > PPL > PolyLib.
>
> This means, we don't change the default behavior of CLooG yet.
> As we still need to discuss some aspects of providing information
> with upstream it is necessary to disable the cloog version check
> (--disable-cloog-version-check) to use one of the upstream
> CLooG versions for now.
>
> After successfully completing all test suites we want to switch
> to CLooG-ISL and abandon the legacy CLooG-PPL.
>

Seconded.  I intend to leave CLooG-PPL with no more changes
other than bug fixes, in particular I will not update CLooG-PPL
to configure with PPL-0.11 to incite people to use CLooG.org.
My intent is to deprecate the use of CLooG-PPL, and remove
support of CLooG-PPL in GCC-4.7.

> Andreas Simbürger (3):
>  Add necessary accessors for CloogMatrix (CLOOG_ORG).

Ok.

>  Fix include order to avoid failed compilation on CLOOG_ORG.

Ok.

>  Support official CLooG.org versions.

We will have to add to CLooG several defines to be able to determine
from configure the version of CLooG and the back-end that will be used
(Parma, ISL, PolyLib).

We need a configure maintainer to approve these changes.
Paolo, could you please have a look at the changes in [PATCH 3/3]?

Thanks,
Sebastian

Re: [PATCH 0/3] Configure support for official CLooG versions.

[Jack Howarth]

On Wed, Aug 11, 2010 at 08:30:09PM +0200, Andreas Simbürger wrote:
> Hi,
> 
> this patch series adds configure support for upstream CLooG versions.
> The official CLooG is able to use three different backends during
> code generation. An ISL backend, a PPL backend and a PolyLib backend.
> 
> Furthermore the old CLooG-PPL (Legacy) fork used by graphite at the
> moment is still supported.
> While checking for the used CLooG version we check in the following
> order: PPL (Legacy) > ISL > PPL > PolyLib.

One issue that remains to be resolved is a mechanism to retain
coherency between the gcc and cloog builds. Currently one can
end up with the following situation...

1) Build and install cloog-ppl against ppl-0.10.2.
2) Build and install FSF gcc against cloog-ppl and ppl-10.2.
3) Build and install ppl-0.11.
4) Rebuild and install cloog-ppl against ppl-0.11.

This creates an ABI mismatch since the calls to cloog
in gcc are compiled using the ppl-0.10.2 headers (as
loaded via cloog.h) while the called subroutine in
the installed cloog was actually built against a
newer ABI from ppl.0.11.
   There should be a cloog call added to allow the
calling program to confirm that the version of isl,
ppl or polylib that it was built against is of the
same ABI as that for the isl, ppl or polylib that
cloog itself was built against.
       Jack

> 
> This means, we don't change the default behavior of CLooG yet.
> As we still need to discuss some aspects of providing information 
> with upstream it is necessary to disable the cloog version check
> (--disable-cloog-version-check) to use one of the upstream
> CLooG versions for now.
> 
> After successfully completing all test suites we want to switch
> to CLooG-ISL and abandon the legacy CLooG-PPL.
> 
> Andreas
> 
> Andreas Simbürger (3):
>   Add necessary accessors for CloogMatrix (CLOOG_ORG).
>   Fix include order to avoid failed compilation on CLOOG_ORG.
>   Support official CLooG.org versions.
> 
>  configure                   |  156 +++++++++++++++++++++++++++++++++++++------
>  configure.ac                |   90 ++++++++++++++++++------
>  gcc/ChangeLog.graphite      |   14 ++++
>  gcc/graphite-cloog-compat.h |   10 +++
>  gcc/graphite-poly.c         |    2 +-
>  5 files changed, 228 insertions(+), 44 deletions(-)
> 
> -- 
> 1.7.2

Re: [PATCH 0/3] Configure support for official CLooG versions.

[Jack Howarth]

On Wed, Aug 11, 2010 at 01:55:00PM -0500, Sebastian Pop wrote:
> On Wed, Aug 11, 2010 at 13:30, Andreas Simbürger
> <simbuerg@googlemail.com> wrote:
> > Hi,
> >
> > this patch series adds configure support for upstream CLooG versions.
> > The official CLooG is able to use three different backends during
> > code generation. An ISL backend, a PPL backend and a PolyLib backend.
> >
> > Furthermore the old CLooG-PPL (Legacy) fork used by graphite at the
> > moment is still supported.
> > While checking for the used CLooG version we check in the following
> > order: PPL (Legacy) > ISL > PPL > PolyLib.
> >
> > This means, we don't change the default behavior of CLooG yet.
> > As we still need to discuss some aspects of providing information
> > with upstream it is necessary to disable the cloog version check
> > (--disable-cloog-version-check) to use one of the upstream
> > CLooG versions for now.
> >
> > After successfully completing all test suites we want to switch
> > to CLooG-ISL and abandon the legacy CLooG-PPL.
> >
> 
> Seconded.  I intend to leave CLooG-PPL with no more changes
> other than bug fixes, in particular I will not update CLooG-PPL
> to configure with PPL-0.11 to incite people to use CLooG.org.
> My intent is to deprecate the use of CLooG-PPL, and remove
> support of CLooG-PPL in GCC-4.7.

Hopefully the soversion in cloog 0.15 from cloog.org will be bumped
from 0 to 1. Otherwise there will be packaging issues due to the
fact that two different cloog distributions (cloog-ppl and cloog.org)
claim the same soversion number. This will force all installed gcc's
to be rebuilt.
        Jack
> 
> > Andreas Simbürger (3):
> >  Add necessary accessors for CloogMatrix (CLOOG_ORG).
> 
> Ok.
> 
> >  Fix include order to avoid failed compilation on CLOOG_ORG.
> 
> Ok.
> 
> >  Support official CLooG.org versions.
> 
> We will have to add to CLooG several defines to be able to determine
> from configure the version of CLooG and the back-end that will be used
> (Parma, ISL, PolyLib).
> 
> We need a configure maintainer to approve these changes.
> Paolo, could you please have a look at the changes in [PATCH 3/3]?
> 
> Thanks,
> Sebastian

Re: [PATCH 0/3] Configure support for official CLooG versions.

[Tobias Grosser]

On 08/11/2010 09:07 PM, Jack Howarth wrote:
> On Wed, Aug 11, 2010 at 01:55:00PM -0500, Sebastian Pop wrote:
>> On Wed, Aug 11, 2010 at 13:30, Andreas Simbürger
>> <simbuerg@googlemail.com>  wrote:
>>> Hi,
>>>
>>> this patch series adds configure support for upstream CLooG versions.
>>> The official CLooG is able to use three different backends during
>>> code generation. An ISL backend, a PPL backend and a PolyLib backend.
>>>
>>> Furthermore the old CLooG-PPL (Legacy) fork used by graphite at the
>>> moment is still supported.
>>> While checking for the used CLooG version we check in the following
>>> order: PPL (Legacy)>  ISL>  PPL>  PolyLib.
>>>
>>> This means, we don't change the default behavior of CLooG yet.
>>> As we still need to discuss some aspects of providing information
>>> with upstream it is necessary to disable the cloog version check
>>> (--disable-cloog-version-check) to use one of the upstream
>>> CLooG versions for now.
>>>
>>> After successfully completing all test suites we want to switch
>>> to CLooG-ISL and abandon the legacy CLooG-PPL.
>>>
>>
>> Seconded.  I intend to leave CLooG-PPL with no more changes
>> other than bug fixes, in particular I will not update CLooG-PPL
>> to configure with PPL-0.11 to incite people to use CLooG.org.
>> My intent is to deprecate the use of CLooG-PPL, and remove
>> support of CLooG-PPL in GCC-4.7.
>
> Hopefully the soversion in cloog 0.15 from cloog.org will be bumped
> from 0 to 1. Otherwise there will be packaging issues due to the
> fact that two different cloog distributions (cloog-ppl and cloog.org)
> claim the same soversion number. This will force all installed gcc's
> to be rebuilt.
>          Jack

All CLooG libraries have different library names.

CLooG (legacy) -> libcloog
CLooG-PARMA    -> libcloog-ppl
CLooG-ISL      -> libcloog-isl
CLooG-polylib  -> libcloog-polylib

So the same library versions are hopefully no problem.

Tobi

Re: [PATCH 0/3] Configure support for official CLooG versions.

[Andreas Simbuerger]

 On 08/11/2010 09:07 PM, Jack Howarth wrote:
> On Wed, Aug 11, 2010 at 01:55:00PM -0500, Sebastian Pop wrote:
>> On Wed, Aug 11, 2010 at 13:30, Andreas Simbürger
>> <simbuerg@googlemail.com> wrote:
>>> Hi,
>>>
>>> this patch series adds configure support for upstream CLooG versions.
>>> The official CLooG is able to use three different backends during
>>> code generation. An ISL backend, a PPL backend and a PolyLib backend.
>>>
>>> Furthermore the old CLooG-PPL (Legacy) fork used by graphite at the
>>> moment is still supported.
>>> While checking for the used CLooG version we check in the following
>>> order: PPL (Legacy) > ISL > PPL > PolyLib.
>>>
>>> This means, we don't change the default behavior of CLooG yet.
>>> As we still need to discuss some aspects of providing information
>>> with upstream it is necessary to disable the cloog version check
>>> (--disable-cloog-version-check) to use one of the upstream
>>> CLooG versions for now.
>>>
>>> After successfully completing all test suites we want to switch
>>> to CLooG-ISL and abandon the legacy CLooG-PPL.
>>>
>> Seconded.  I intend to leave CLooG-PPL with no more changes
>> other than bug fixes, in particular I will not update CLooG-PPL
>> to configure with PPL-0.11 to incite people to use CLooG.org.
>> My intent is to deprecate the use of CLooG-PPL, and remove
>> support of CLooG-PPL in GCC-4.7.
> Hopefully the soversion in cloog 0.15 from cloog.org will be bumped
> from 0 to 1. Otherwise there will be packaging issues due to the
> fact that two different cloog distributions (cloog-ppl and cloog.org)
> claim the same soversion number. This will force all installed gcc's
> to be rebuilt.
>         Jack
The CLooG.org versions use different sonames for the libraries, depending
on the backend:
 - libcloog-isl.so (.0)
 - libcloog-ppl.so (.0)
 - libcloog-polylib.so (.0)

while CLooG-PPL uses 'libcloog.so (.0)'. This should avoid clashes
with soversions on existing installations.

Andreas
>>> Andreas Simbürger (3):
>>>  Add necessary accessors for CloogMatrix (CLOOG_ORG).
>> Ok.
>>
>>>  Fix include order to avoid failed compilation on CLOOG_ORG.
>> Ok.
>>
>>>  Support official CLooG.org versions.
>> We will have to add to CLooG several defines to be able to determine
>> from configure the version of CLooG and the back-end that will be used
>> (Parma, ISL, PolyLib).
>>
>> We need a configure maintainer to approve these changes.
>> Paolo, could you please have a look at the changes in [PATCH 3/3]?
>>
>> Thanks,
>> Sebastian

Re: [PATCH 0/3] Configure support for official CLooG versions.

[Andreas Simbuerger]

 On 08/11/2010 09:02 PM, Jack Howarth wrote:
> On Wed, Aug 11, 2010 at 08:30:09PM +0200, Andreas Simbürger wrote:
>> Hi,
>>
>> this patch series adds configure support for upstream CLooG versions.
>> The official CLooG is able to use three different backends during
>> code generation. An ISL backend, a PPL backend and a PolyLib backend.
>>
>> Furthermore the old CLooG-PPL (Legacy) fork used by graphite at the
>> moment is still supported.
>> While checking for the used CLooG version we check in the following
>> order: PPL (Legacy) > ISL > PPL > PolyLib.
> One issue that remains to be resolved is a mechanism to retain
> coherency between the gcc and cloog builds. Currently one can
> end up with the following situation...
>
> 1) Build and install cloog-ppl against ppl-0.10.2.
> 2) Build and install FSF gcc against cloog-ppl and ppl-10.2.
> 3) Build and install ppl-0.11.
> 4) Rebuild and install cloog-ppl against ppl-0.11.
>
> This creates an ABI mismatch since the calls to cloog
> in gcc are compiled using the ppl-0.10.2 headers (as
> loaded via cloog.h) while the called subroutine in
> the installed cloog was actually built against a
> newer ABI from ppl.0.11.
>    There should be a cloog call added to allow the
> calling program to confirm that the version of isl,
> ppl or polylib that it was built against is of the
> same ABI as that for the isl, ppl or polylib that
> cloog itself was built against.
>        Jack
This is true. However CLooG-PPL on the one hand cannot be built with
PPL-0.11 as the
configure script explicitly checks for PPL-0.10.

(cloog-ppl/configure.in:313 ff.)

GCC on the other hand would accept PPL-0.11 in configure, but i don't know
if it compiles.
I can handle this scenario as soon as i get a better way of retreiving
CLooG version
information about the used backend from upstream (WIP).

Andreas

Re: [PATCH 1/3] Add necessary accessors for CloogMatrix (CLOOG_ORG).

[Sebastian Pop]

On Wed, Aug 11, 2010 at 13:30, Andreas Simbürger
<simbuerg@googlemail.com> wrote:
> 2010-08-11  Andreas Simbuerger  <simbuerg@fim.uni-passau.de>
>
>        * graphite-cloog-compat.h (cloog_matrix_ncolumns): New.
>        (cloog_matrix_nrows): New.

Committed to the graphite branch.

Re: [PATCH 2/3] Fix include order to avoid failed compilation on CLOOG_ORG.

[Sebastian Pop]

On Wed, Aug 11, 2010 at 13:30, Andreas Simbürger
<simbuerg@googlemail.com> wrote:
> 2010-08-11  Andreas Simbuerger  <simbuerg@fim.uni-passau.de>
>
>        * graphite-poly.c: Change include order.

Committed to the graphite branch.

Re: [PATCH 0/3] Configure support for official CLooG versions.

[Matthias Klose]

On 11.08.2010 21:22, Andreas Simbuerger wrote:
>   On 08/11/2010 09:07 PM, Jack Howarth wrote:
>> On Wed, Aug 11, 2010 at 01:55:00PM -0500, Sebastian Pop wrote:
>>> On Wed, Aug 11, 2010 at 13:30, Andreas Simbürger
>>> <simbuerg@googlemail.com>  wrote:
>>>> Hi,
>>>>
>>>> this patch series adds configure support for upstream CLooG versions.
>>>> The official CLooG is able to use three different backends during
>>>> code generation. An ISL backend, a PPL backend and a PolyLib backend.
>>>>
>>>> Furthermore the old CLooG-PPL (Legacy) fork used by graphite at the
>>>> moment is still supported.
>>>> While checking for the used CLooG version we check in the following
>>>> order: PPL (Legacy)>  ISL>  PPL>  PolyLib.
>>>>
>>>> This means, we don't change the default behavior of CLooG yet.
>>>> As we still need to discuss some aspects of providing information
>>>> with upstream it is necessary to disable the cloog version check
>>>> (--disable-cloog-version-check) to use one of the upstream
>>>> CLooG versions for now.
>>>>
>>>> After successfully completing all test suites we want to switch
>>>> to CLooG-ISL and abandon the legacy CLooG-PPL.
>>>>
>>> Seconded.  I intend to leave CLooG-PPL with no more changes
>>> other than bug fixes, in particular I will not update CLooG-PPL
>>> to configure with PPL-0.11 to incite people to use CLooG.org.
>>> My intent is to deprecate the use of CLooG-PPL, and remove
>>> support of CLooG-PPL in GCC-4.7.
>> Hopefully the soversion in cloog 0.15 from cloog.org will be bumped
>> from 0 to 1. Otherwise there will be packaging issues due to the
>> fact that two different cloog distributions (cloog-ppl and cloog.org)
>> claim the same soversion number. This will force all installed gcc's
>> to be rebuilt.
>>          Jack
> The CLooG.org versions use different sonames for the libraries, depending
> on the backend:
>   - libcloog-isl.so (.0)
>   - libcloog-ppl.so (.0)
>   - libcloog-polylib.so (.0)
>
> while CLooG-PPL uses 'libcloog.so (.0)'. This should avoid clashes
> with soversions on existing installations.

except that the Debian package already uses libcloog-ppl.so (.0) for the patched 
CLooG-PPL :-/  A version bump would be appreciated.  Sorry for addressing this 
in the distribution before upstream.

   Matthias

Re: [PATCH 0/3] Configure support for official CLooG versions.

[Joseph S. Myers]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1028 bytes --]

On Wed, 11 Aug 2010, Andreas Simbürger wrote:

> this patch series adds configure support for upstream CLooG versions.
> The official CLooG is able to use three different backends during
> code generation. An ISL backend, a PPL backend and a PolyLib backend.

Does ISL involve another library that would be linked against instead of 
PPL, that needs installing separately from CLooG?  If so, this patch 
series appears incomplete, as it doesn't include any addition of 
information about ISL to install.texi, or --with-isl etc. options 
analogous to the --with-ppl options, or configure code that adds -lisl or 
similar (as opposed to -lcloog-isl).  All these things are needed for 
making GCC link with a new host-side library.  In addition it will be 
necessary to check the portability of ISL to different hosts, similarly to 
how people tested PPL on various hosts before the original Graphite merge, 
including cases such as building it with cross compilers.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [PATCH 0/3] Configure support for official CLooG versions.

[Andreas Simbuerger]

 On 08/11/2010 11:55 PM, Joseph S. Myers wrote:
> On Wed, 11 Aug 2010, Andreas Simbürger wrote:
>
>> this patch series adds configure support for upstream CLooG versions.
>> The official CLooG is able to use three different backends during
>> code generation. An ISL backend, a PPL backend and a PolyLib backend.
> Does ISL involve another library that would be linked against instead of 
> PPL, that needs installing separately from CLooG?  If so, this patch 
> series appears incomplete, as it doesn't include any addition of 
> information about ISL to install.texi, or --with-isl etc. options 
> analogous to the --with-ppl options, or configure code that adds -lisl or 
> similar (as opposed to -lcloog-isl).  All these things are needed for 
> making GCC link with a new host-side library.  In addition it will be 
> necessary to check the portability of ISL to different hosts, similarly to 
> how people tested PPL on various hosts before the original Graphite merge, 
> including cases such as building it with cross compilers.
>
The Integer Set Library (ISL) is used within CLooG's backend instead
of the PPL (Another backend using the PolyLib is available too).
The official CLooG version provides it's own ISL bundle which
get's installed alongside CLooG itself. The ISL is exclusively used by
CLooG for now.

This patch series only prepare GCC for the transition from the CLooG-PPL
fork,
maintained by Graphite to the CLooG versions maintained by upstream.

Regards,
Andreas

Re: [PATCH 0/3] Configure support for official CLooG versions.

[Joseph S. Myers]

On Thu, 12 Aug 2010, Andreas Simbuerger wrote:

> The Integer Set Library (ISL) is used within CLooG's backend instead
> of the PPL (Another backend using the PolyLib is available too).
> The official CLooG version provides it's own ISL bundle which
> get's installed alongside CLooG itself. The ISL is exclusively used by
> CLooG for now.

Do you mean that ISL is a part of the libcloog-isl library, so that no 
separate -lisl option is ever going to be needed when linking anything (in 
particular, when using static libraries so shared library dependencies are 
not available)?  There are several questions:

* Is ISL source part of the CLooG tarball or a separate tarball?  If a 
separate tarball, install.texi needs to explain this.

* Is ISL included in the libcloog-isl library binary or is it a separate 
library binary?  If a separate binary, the configure code needs to link 
against it explicitly.

* Does ISL depend on other libraries, like PPL depends on -lgmp -lgmpxx 
-lstdc++?  If so, then the configure code needs to know about these and if 
libstdc++ is involved then the documentation of --with-host-libstdcxx may 
need updating as well.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [PATCH 0/3] Configure support for official CLooG versions.

[Roberto Bagnara]

On 08/11/10 20:55, Sebastian Pop wrote:
> On Wed, Aug 11, 2010 at 13:30, Andreas Simbürger
> <simbuerg@googlemail.com>  wrote:
>>   Support official CLooG.org versions.
>
> We will have to add to CLooG several defines to be able to determine
> from configure the version of CLooG and the back-end that will be used
> (Parma, ISL, PolyLib).

OK, but please do not call our library "Parma": it is either "PPL"
or "Parma Polyhedra Library"
(see http://www.cs.unipr.it/ppl/FAQ#Library_Name).
Thanks,

    Roberto

-- 
Prof. Roberto Bagnara
Applied Formal Methods Laboratory
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:bagnara@cs.unipr.it

Re: [PATCH 0/3] Configure support for official CLooG versions.

[Andreas Simbuerger]

 On 08/12/2010 12:33 AM, Joseph S. Myers wrote:
> On Thu, 12 Aug 2010, Andreas Simbuerger wrote:
>
>> The Integer Set Library (ISL) is used within CLooG's backend instead
>> of the PPL (Another backend using the PolyLib is available too).
>> The official CLooG version provides it's own ISL bundle which
>> get's installed alongside CLooG itself. The ISL is exclusively used by
>> CLooG for now.
> Do you mean that ISL is a part of the libcloog-isl library, so that no 
> separate -lisl option is ever going to be needed when linking anything (in 
> particular, when using static libraries so shared library dependencies are 
> not available)?  There are several questions:
>
> * Is ISL source part of the CLooG tarball or a separate tarball?  If a 
> separate tarball, install.texi needs to explain this.
>
The ISL is in fact a separate library, but the CLooG tarball is bundled
with a working release of it. You can configure CLooG with an out-of-tree
ISL version, but the default setting is to use the bundled ISL.
By default CLooG's ISL gets installed into CLooG's install dir and is
covered
by CLooG's library path.
> * Is ISL included in the libcloog-isl library binary or is it a separate 
> library binary?  If a separate binary, the configure code needs to link 
> against it explicitly.
As mentioned above, it is a separate library. I don't fully understand why
it is required to link to unused code? The ISL is never required by GCC.
Ideally i do not want to know which backend CLooG is using for its'
code generation.
> * Does ISL depend on other libraries, like PPL depends on -lgmp -lgmpxx 
> -lstdc++?  If so, then the configure code needs to know about these and if 
> libstdc++ is involved then the documentation of --with-host-libstdcxx may 
> need updating as well.
>
The ISL depends on -lgmp.

Andreas

Re: [PATCH 0/3] Configure support for official CLooG versions.

[Joseph S. Myers]

On Thu, 12 Aug 2010, Andreas Simbuerger wrote:

> > * Is ISL source part of the CLooG tarball or a separate tarball?  If a 
> > separate tarball, install.texi needs to explain this.
> >
> The ISL is in fact a separate library, but the CLooG tarball is bundled
> with a working release of it. You can configure CLooG with an out-of-tree
> ISL version, but the default setting is to use the bundled ISL.
> By default CLooG's ISL gets installed into CLooG's install dir and is
> covered
> by CLooG's library path.

What do you mean by "covered by CLooG's library path"?  Do you mean that 
libisl.a is in the same directory as libcloog-isl.a, so that a single -L 
option suffices to find both?  Or do you mean that all objects in libisl.a 
that are required to use libcloog-isl.a are also included in 
libcloog-isl.a so there is no need to link against any other library?

> > * Is ISL included in the libcloog-isl library binary or is it a separate 
> > library binary?  If a separate binary, the configure code needs to link 
> > against it explicitly.
> As mentioned above, it is a separate library. I don't fully understand why
> it is required to link to unused code? The ISL is never required by GCC.

This is not about unused code, it is about dependencies.  If you use the 
ISL-independent interfaces from libcloog-isl.a, will the object files used 
from that library have unresolved references to symbols in libisl.a or 
some other library?  If the CLooG library depends on symbols defined in a 
separate library, it is necessary to link against that separate library 
explicitly, since static libraries do not carry dependency information.  
If the CLooG library is self-contained - only depends on libraries that 
GCC always links with anyway, such as libc and libgmp, and includes all 
relevant ISL objects within libcloog-isl.a - then this is not necssary.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [PATCH 0/3] Configure support for official CLooG versions.

[Jack Howarth]

On Thu, Aug 12, 2010 at 12:25:21AM +0200, Andreas Simbuerger wrote:
>  On 08/11/2010 11:55 PM, Joseph S. Myers wrote:
> > On Wed, 11 Aug 2010, Andreas Simbürger wrote:
> >
> >> this patch series adds configure support for upstream CLooG versions.
> >> The official CLooG is able to use three different backends during
> >> code generation. An ISL backend, a PPL backend and a PolyLib backend.
> > Does ISL involve another library that would be linked against instead of 
> > PPL, that needs installing separately from CLooG?  If so, this patch 
> > series appears incomplete, as it doesn't include any addition of 
> > information about ISL to install.texi, or --with-isl etc. options 
> > analogous to the --with-ppl options, or configure code that adds -lisl or 
> > similar (as opposed to -lcloog-isl).  All these things are needed for 
> > making GCC link with a new host-side library.  In addition it will be 
> > necessary to check the portability of ISL to different hosts, similarly to 
> > how people tested PPL on various hosts before the original Graphite merge, 
> > including cases such as building it with cross compilers.
> >
> The Integer Set Library (ISL) is used within CLooG's backend instead
> of the PPL (Another backend using the PolyLib is available too).
> The official CLooG version provides it's own ISL bundle which
> get's installed alongside CLooG itself. The ISL is exclusively used by
> CLooG for now.

Andreas,
    Are there any benchmarks comparing the performance of graphite with
cloog-isl, cloog-polylib and cloog-ppl? In particular, how do the three
compare in effectiveness of properly finding loops and are there large
differences in the time they require to process the data? I had assumed
that cloog-ppl built against ppl-0.11 would be the preferred option
for graphite in gcc 4.6.
                    Jack
> 
> This patch series only prepare GCC for the transition from the CLooG-PPL
> fork,
> maintained by Graphite to the CLooG versions maintained by upstream.
> 
> Regards,
> Andreas
> 

Re: [PATCH 0/3] Configure support for official CLooG versions.

[Andreas Simbuerger]

 On 08/12/2010 03:39 PM, Jack Howarth wrote:
> On Thu, Aug 12, 2010 at 12:25:21AM +0200, Andreas Simbuerger wrote:
>>  On 08/11/2010 11:55 PM, Joseph S. Myers wrote:
>>> On Wed, 11 Aug 2010, Andreas Simbürger wrote:
>>>
>>>> this patch series adds configure support for upstream CLooG versions.
>>>> The official CLooG is able to use three different backends during
>>>> code generation. An ISL backend, a PPL backend and a PolyLib backend.
>>> Does ISL involve another library that would be linked against instead of 
>>> PPL, that needs installing separately from CLooG?  If so, this patch 
>>> series appears incomplete, as it doesn't include any addition of 
>>> information about ISL to install.texi, or --with-isl etc. options 
>>> analogous to the --with-ppl options, or configure code that adds -lisl or 
>>> similar (as opposed to -lcloog-isl).  All these things are needed for 
>>> making GCC link with a new host-side library.  In addition it will be 
>>> necessary to check the portability of ISL to different hosts, similarly to 
>>> how people tested PPL on various hosts before the original Graphite merge, 
>>> including cases such as building it with cross compilers.
>>>
>> The Integer Set Library (ISL) is used within CLooG's backend instead
>> of the PPL (Another backend using the PolyLib is available too).
>> The official CLooG version provides it's own ISL bundle which
>> get's installed alongside CLooG itself. The ISL is exclusively used by
>> CLooG for now.
> Andreas,
>     Are there any benchmarks comparing the performance of graphite with
> cloog-isl, cloog-polylib and cloog-ppl? In particular, how do the three
> compare in effectiveness of properly finding loops and are there large
> differences in the time they require to process the data? I had assumed
> that cloog-ppl built against ppl-0.11 would be the preferred option
> for graphite in gcc 4.6.
>                     Jack

Tests will follow. We wanted to discuss the configure changes in the
first place. After that we apply them to the graphite branch and
evaluate the performance of the backends. We assume
that the CLooG-ISL will be superior over the alternatives in most cases.

The CLooG-PPL fork that is used now should be deprecated, as it is
not maintained from upstream at all.

I will post benchmark results as i get the patches applied to the
graphite branch.

Andreas
>> This patch series only prepare GCC for the transition from the CLooG-PPL
>> fork,
>> maintained by Graphite to the CLooG versions maintained by upstream.
>>
>> Regards,
>> Andreas
>>

Re: [PATCH 0/3] Configure support for official CLooG versions.

[Jack Howarth]

Andreas,
   If we want to test the upcoming cloog.org 0.15 release,
is the http://repo.or.cz/w/cloog.git effectively it or
is there some other source?
           Jack

Re: [PATCH 0/3] Configure support for official CLooG versions.

[Andreas Simbuerger]

 On 08/12/2010 11:56 AM, Joseph S. Myers wrote:
> On Thu, 12 Aug 2010, Andreas Simbuerger wrote:
>
>>> * Is ISL source part of the CLooG tarball or a separate tarball?  If a 
>>> separate tarball, install.texi needs to explain this.
>>>
>> The ISL is in fact a separate library, but the CLooG tarball is bundled
>> with a working release of it. You can configure CLooG with an out-of-tree
>> ISL version, but the default setting is to use the bundled ISL.
>> By default CLooG's ISL gets installed into CLooG's install dir and is
>> covered
>> by CLooG's library path.
> What do you mean by "covered by CLooG's library path"?  Do you mean that 
> libisl.a is in the same directory as libcloog-isl.a, so that a single -L 
> option suffices to find both?  Or do you mean that all objects in libisl.a 
> that are required to use libcloog-isl.a are also included in 
> libcloog-isl.a so there is no need to link against any other library?
>
Sorry I was unprecise with that. You're right, libcloog-isl.a and
libisl.a share
the install directory when using the bundled ISL version.
>>> * Is ISL included in the libcloog-isl library binary or is it a separate 
>>> library binary?  If a separate binary, the configure code needs to link 
>>> against it explicitly.
>> As mentioned above, it is a separate library. I don't fully understand why
>> it is required to link to unused code? The ISL is never required by GCC.
> This is not about unused code, it is about dependencies.  If you use the 
> ISL-independent interfaces from libcloog-isl.a, will the object files used 
> from that library have unresolved references to symbols in libisl.a or 
> some other library?  If the CLooG library depends on symbols defined in a 
> separate library, it is necessary to link against that separate library 
> explicitly, since static libraries do not carry dependency information.  
> If the CLooG library is self-contained - only depends on libraries that 
> GCC always links with anyway, such as libc and libgmp, and includes all 
> relevant ISL objects within libcloog-isl.a - then this is not necssary.
 
Thanks for explaining this, i will have to read more on that topic + check.
Never had a problem with compiling/linking and didn't bother any further ;-)
I will have to update the configure patch to support all scenarios for
the ISL.

Andreas

Re: [PATCH 0/3] Configure support for official CLooG versions.

[Jack Howarth]

Andreas,
   Is it possible that cloog.org's cloog 0.15 release
could be modified to require ppl 0.11 or later? This
might be useful way to handle the transition of both
ppl from 0.10.x to 0.11 and cloog-ppl to cloog.org.
Since it seems unlikely that gcc 4.5.x will be fixed
to build against cloog.org and cloog-ppl can't build
against ppl-0.11, this locks gcc 4.5.x and earlier
in at cloog-ppl 0.15.9/ppl 0.10.2. If gcc 4.6 is
configured to only build against cloog.org (and not
cloog-ppl), we won't have to worry about which ppl
release gcc 4.6 is built against (since it must
be ppl 0.11 or later to satisfy cloog 0.15).
            Jack

Re: [PATCH 0/3] Configure support for official CLooG versions.

[Andreas Simbuerger]

 On 08/12/2010 09:41 PM, Jack Howarth wrote:
> Andreas,
>    If we want to test the upcoming cloog.org 0.15 release,
> is the http://repo.or.cz/w/cloog.git effectively it or
> is there some other source?
>            Jack
That is the official one :-) There exist two other backends
at:
http://repo.or.cz/r/cloog-polylib.git (CLooG-PolyLib) and
http://repo.or.cz/w/cloog-parma.git (CLooG-Parma).

Andreas

Re: [PATCH 0/3] Configure support for official CLooG versions.

[Andreas Simbuerger]

 On 08/13/2010 04:35 PM, Jack Howarth wrote:
> Andreas,
>    Is it possible that cloog.org's cloog 0.15 release
> could be modified to require ppl 0.11 or later? This
> might be useful way to handle the transition of both
> ppl from 0.10.x to 0.11 and cloog-ppl to cloog.org.
> Since it seems unlikely that gcc 4.5.x will be fixed
> to build against cloog.org and cloog-ppl can't build
> against ppl-0.11, this locks gcc 4.5.x and earlier
> in at cloog-ppl 0.15.9/ppl 0.10.2. If gcc 4.6 is
> configured to only build against cloog.org (and not
> cloog-ppl), we won't have to worry about which ppl
> release gcc 4.6 is built against (since it must
> be ppl 0.11 or later to satisfy cloog 0.15).
>             Jack

I have to discuss this on the next graphite call.
As far is i remember Sebastian did not want to
extend CLooG-PPL any further, except critical bugs.

I will have a look.

Andreas

Re: [PATCH 0/3] Configure support for official CLooG versions.

[Jack Howarth]

On Fri, Aug 13, 2010 at 06:07:34PM +0200, Andreas Simbuerger wrote:
>  On 08/12/2010 09:41 PM, Jack Howarth wrote:
> > Andreas,
> >    If we want to test the upcoming cloog.org 0.15 release,
> > is the http://repo.or.cz/w/cloog.git effectively it or
> > is there some other source?
> >            Jack
> That is the official one :-) There exist two other backends
> at:
> http://repo.or.cz/r/cloog-polylib.git (CLooG-PolyLib) and
> http://repo.or.cz/w/cloog-parma.git (CLooG-Parma).

Does this imply that each cloog.org release will have three
tarballs or will those backends all get merged for each
cloog release into a single source tree?
                       Jack

> 
> Andreas

Re: [PATCH 0/3] Configure support for official CLooG versions.

[Andreas Simbuerger]

 On 08/13/2010 06:13 PM, Jack Howarth wrote:
> On Fri, Aug 13, 2010 at 06:07:34PM +0200, Andreas Simbuerger wrote:
>>  On 08/12/2010 09:41 PM, Jack Howarth wrote:
>>> Andreas,
>>>    If we want to test the upcoming cloog.org 0.15 release,
>>> is the http://repo.or.cz/w/cloog.git effectively it or
>>> is there some other source?
>>>            Jack
>> That is the official one :-) There exist two other backends
>> at:
>> http://repo.or.cz/r/cloog-polylib.git (CLooG-PolyLib) and
>> http://repo.or.cz/w/cloog-parma.git (CLooG-Parma).
> Does this imply that each cloog.org release will have three
> tarballs or will those backends all get merged for each
> cloog release into a single source tree?
>                        Jack
>
After evaluation we will choose the 'best' for the general case.
We believe it will get CLooG-ISL, as it gets the most attention from
upstream.

Andreas
>> Andreas

Re: [PATCH 0/3] Configure support for official CLooG versions.

[Sebastian Pop]

On Fri, Aug 13, 2010 at 11:09, Andreas Simbuerger
<simbuerg@googlemail.com> wrote:
>  On 08/13/2010 04:35 PM, Jack Howarth wrote:
>> Andreas,
>>    Is it possible that cloog.org's cloog 0.15 release
>> could be modified to require ppl 0.11 or later? This
>> might be useful way to handle the transition of both
>> ppl from 0.10.x to 0.11 and cloog-ppl to cloog.org.
>> Since it seems unlikely that gcc 4.5.x will be fixed
>> to build against cloog.org and cloog-ppl can't build
>> against ppl-0.11, this locks gcc 4.5.x and earlier
>> in at cloog-ppl 0.15.9/ppl 0.10.2. If gcc 4.6 is
>> configured to only build against cloog.org (and not
>> cloog-ppl), we won't have to worry about which ppl
>> release gcc 4.6 is built against (since it must
>> be ppl 0.11 or later to satisfy cloog 0.15).
>>             Jack
>
> I have to discuss this on the next graphite call.
> As far is i remember Sebastian did not want to
> extend CLooG-PPL any further, except critical bugs.

Right.  Jack's proposal is ok from my point of view.

Sebastian

Re: [PATCH 0/3] Configure support for official CLooG versions.

[Gerald Pfeifer]

On Wed, 11 Aug 2010, Sebastian Pop wrote:
> Seconded.  I intend to leave CLooG-PPL with no more changes other than 
> bug fixes, in particular I will not update CLooG-PPL to configure with 
> PPL-0.11 to incite people to use CLooG.org. My intent is to deprecate 
> the use of CLooG-PPL, and remove support of CLooG-PPL in GCC-4.7.

Given how new (nearly experimental) CLooG is for GCC 4.5, I am wondering 
whether you couldn't just make the change with GCC 4.6 without any 
deprecation period.  If it were me, that's what I'd be doing. :-)

Gerald

Re: [PATCH 0/3] Configure support for official CLooG versions.

[Richard Guenther]

On Sat, Aug 21, 2010 at 10:44 AM, Gerald Pfeifer <gerald@pfeifer.com> wrote:
> On Wed, 11 Aug 2010, Sebastian Pop wrote:
>> Seconded.  I intend to leave CLooG-PPL with no more changes other than
>> bug fixes, in particular I will not update CLooG-PPL to configure with
>> PPL-0.11 to incite people to use CLooG.org. My intent is to deprecate
>> the use of CLooG-PPL, and remove support of CLooG-PPL in GCC-4.7.
>
> Given how new (nearly experimental) CLooG is for GCC 4.5, I am wondering
> whether you couldn't just make the change with GCC 4.6 without any
> deprecation period.  If it were me, that's what I'd be doing. :-)

Yes.  Please consider forcing the upgrade for GCC 4.6 (together with using
upstream cloog, to avoid the soname clash).

Richard.

> Gerald
>