* [PATCH 2/3] Fix include order to avoid failed compilation on CLOOG_ORG. [not found] <cloog1> @ 2010-08-11 18:30 ` Andreas Simbürger 2010-08-11 21:01 ` Sebastian Pop 2010-08-11 18:30 ` [PATCH 1/3] Add necessary accessors for CloogMatrix (CLOOG_ORG) Andreas Simbürger ` (2 subsequent siblings) 3 siblings, 1 reply; 31+ messages in thread From: Andreas Simbürger @ 2010-08-11 18:30 UTC (permalink / raw) To: gcc-graphite; +Cc: gcc-patches, 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 2/3] Fix include order to avoid failed compilation on CLOOG_ORG. 2010-08-11 18:30 ` [PATCH 2/3] Fix include order to avoid failed compilation on CLOOG_ORG Andreas Simbürger @ 2010-08-11 21:01 ` Sebastian Pop 0 siblings, 0 replies; 31+ messages in thread From: Sebastian Pop @ 2010-08-11 21:01 UTC (permalink / raw) To: Andreas Simbürger; +Cc: gcc-graphite, gcc-patches 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. ^ permalink raw reply [flat|nested] 31+ messages in thread
* [PATCH 1/3] Add necessary accessors for CloogMatrix (CLOOG_ORG). [not found] <cloog1> 2010-08-11 18:30 ` [PATCH 2/3] Fix include order to avoid failed compilation on CLOOG_ORG Andreas Simbürger @ 2010-08-11 18:30 ` Andreas Simbürger 2010-08-11 20:54 ` Sebastian Pop 2010-08-11 18:30 ` [PATCH 0/3] Configure support for official CLooG versions Andreas Simbürger 2010-08-11 18:45 ` [PATCH 3/3] Support official CLooG.org versions Andreas Simbürger 3 siblings, 1 reply; 31+ messages in thread From: Andreas Simbürger @ 2010-08-11 18:30 UTC (permalink / raw) To: gcc-graphite; +Cc: gcc-patches, 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 1/3] Add necessary accessors for CloogMatrix (CLOOG_ORG). 2010-08-11 18:30 ` [PATCH 1/3] Add necessary accessors for CloogMatrix (CLOOG_ORG) Andreas Simbürger @ 2010-08-11 20:54 ` Sebastian Pop 0 siblings, 0 replies; 31+ messages in thread From: Sebastian Pop @ 2010-08-11 20:54 UTC (permalink / raw) To: Andreas Simbürger; +Cc: gcc-graphite, gcc-patches 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. ^ permalink raw reply [flat|nested] 31+ messages in thread
* [PATCH 0/3] Configure support for official CLooG versions. [not found] <cloog1> 2010-08-11 18:30 ` [PATCH 2/3] Fix include order to avoid failed compilation on CLOOG_ORG Andreas Simbürger 2010-08-11 18:30 ` [PATCH 1/3] Add necessary accessors for CloogMatrix (CLOOG_ORG) Andreas Simbürger @ 2010-08-11 18:30 ` Andreas Simbürger 2010-08-11 19:02 ` Sebastian Pop ` (2 more replies) 2010-08-11 18:45 ` [PATCH 3/3] Support official CLooG.org versions Andreas Simbürger 3 siblings, 3 replies; 31+ messages in thread From: Andreas Simbürger @ 2010-08-11 18:30 UTC (permalink / raw) To: gcc-graphite; +Cc: gcc-patches, 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 0/3] Configure support for official CLooG versions. 2010-08-11 18:30 ` [PATCH 0/3] Configure support for official CLooG versions Andreas Simbürger @ 2010-08-11 19:02 ` Sebastian Pop 2010-08-11 19:18 ` Jack Howarth ` (3 more replies) 2010-08-11 19:08 ` Jack Howarth 2010-08-11 22:13 ` Joseph S. Myers 2 siblings, 4 replies; 31+ messages in thread From: Sebastian Pop @ 2010-08-11 19:02 UTC (permalink / raw) To: Andreas Simbürger, Paolo Bonzini; +Cc: gcc-graphite, gcc-patches 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 0/3] Configure support for official CLooG versions. 2010-08-11 19:02 ` Sebastian Pop @ 2010-08-11 19:18 ` Jack Howarth 2010-08-11 19:27 ` Andreas Simbuerger [not found] ` <2876_1281553691_4C62F51B_2876_2281_1_20100811190756.GB18599@bromo.med.uc.edu> ` (2 subsequent siblings) 3 siblings, 1 reply; 31+ messages in thread From: Jack Howarth @ 2010-08-11 19:18 UTC (permalink / raw) To: Sebastian Pop Cc: Andreas Simbürger, Paolo Bonzini, gcc-graphite, gcc-patches 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 0/3] Configure support for official CLooG versions. 2010-08-11 19:18 ` Jack Howarth @ 2010-08-11 19:27 ` Andreas Simbuerger 2010-08-11 21:55 ` Matthias Klose 0 siblings, 1 reply; 31+ messages in thread From: Andreas Simbuerger @ 2010-08-11 19:27 UTC (permalink / raw) To: Jack Howarth; +Cc: Sebastian Pop, Paolo Bonzini, gcc-graphite, gcc-patches 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 0/3] Configure support for official CLooG versions. 2010-08-11 19:27 ` Andreas Simbuerger @ 2010-08-11 21:55 ` Matthias Klose 0 siblings, 0 replies; 31+ messages in thread From: Matthias Klose @ 2010-08-11 21:55 UTC (permalink / raw) To: Andreas Simbuerger Cc: Jack Howarth, Sebastian Pop, Paolo Bonzini, gcc-graphite, gcc-patches 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
[parent not found: <2876_1281553691_4C62F51B_2876_2281_1_20100811190756.GB18599@bromo.med.uc.edu>]
* Re: [PATCH 0/3] Configure support for official CLooG versions. [not found] ` <2876_1281553691_4C62F51B_2876_2281_1_20100811190756.GB18599@bromo.med.uc.edu> @ 2010-08-11 19:23 ` Tobias Grosser 0 siblings, 0 replies; 31+ messages in thread From: Tobias Grosser @ 2010-08-11 19:23 UTC (permalink / raw) To: Jack Howarth Cc: Sebastian Pop, Andreas Simbürger, Paolo Bonzini, gcc-graphite, gcc-patches 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 0/3] Configure support for official CLooG versions. 2010-08-11 19:02 ` Sebastian Pop 2010-08-11 19:18 ` Jack Howarth [not found] ` <2876_1281553691_4C62F51B_2876_2281_1_20100811190756.GB18599@bromo.med.uc.edu> @ 2010-08-12 6:14 ` Roberto Bagnara 2010-08-21 9:16 ` Gerald Pfeifer 3 siblings, 0 replies; 31+ messages in thread From: Roberto Bagnara @ 2010-08-12 6:14 UTC (permalink / raw) To: Sebastian Pop Cc: Andreas Simbürger, Paolo Bonzini, gcc-graphite, gcc-patches 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 0/3] Configure support for official CLooG versions. 2010-08-11 19:02 ` Sebastian Pop ` (2 preceding siblings ...) 2010-08-12 6:14 ` Roberto Bagnara @ 2010-08-21 9:16 ` Gerald Pfeifer 2010-08-23 16:51 ` Richard Guenther 3 siblings, 1 reply; 31+ messages in thread From: Gerald Pfeifer @ 2010-08-21 9:16 UTC (permalink / raw) To: Sebastian Pop Cc: Andreas Simbürger, Paolo Bonzini, gcc-graphite, gcc-patches 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 0/3] Configure support for official CLooG versions. 2010-08-21 9:16 ` Gerald Pfeifer @ 2010-08-23 16:51 ` Richard Guenther 0 siblings, 0 replies; 31+ messages in thread From: Richard Guenther @ 2010-08-23 16:51 UTC (permalink / raw) To: Gerald Pfeifer Cc: Sebastian Pop, Andreas Simbürger, Paolo Bonzini, gcc-graphite, gcc-patches 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 > ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 0/3] Configure support for official CLooG versions. 2010-08-11 18:30 ` [PATCH 0/3] Configure support for official CLooG versions Andreas Simbürger 2010-08-11 19:02 ` Sebastian Pop @ 2010-08-11 19:08 ` Jack Howarth 2010-08-11 20:37 ` Andreas Simbuerger 2010-08-11 22:13 ` Joseph S. Myers 2 siblings, 1 reply; 31+ messages in thread From: Jack Howarth @ 2010-08-11 19:08 UTC (permalink / raw) To: Andreas Simbürger; +Cc: gcc-graphite, gcc-patches 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 0/3] Configure support for official CLooG versions. 2010-08-11 19:08 ` Jack Howarth @ 2010-08-11 20:37 ` Andreas Simbuerger 0 siblings, 0 replies; 31+ messages in thread From: Andreas Simbuerger @ 2010-08-11 20:37 UTC (permalink / raw) To: Jack Howarth; +Cc: gcc-graphite, gcc-patches 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 0/3] Configure support for official CLooG versions. 2010-08-11 18:30 ` [PATCH 0/3] Configure support for official CLooG versions Andreas Simbürger 2010-08-11 19:02 ` Sebastian Pop 2010-08-11 19:08 ` Jack Howarth @ 2010-08-11 22:13 ` Joseph S. Myers 2010-08-11 22:34 ` Andreas Simbuerger 2 siblings, 1 reply; 31+ messages in thread From: Joseph S. Myers @ 2010-08-11 22:13 UTC (permalink / raw) To: Andreas Simbürger; +Cc: gcc-graphite, gcc-patches [-- 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 0/3] Configure support for official CLooG versions. 2010-08-11 22:13 ` Joseph S. Myers @ 2010-08-11 22:34 ` Andreas Simbuerger 2010-08-11 23:39 ` Joseph S. Myers 2010-08-12 13:39 ` Jack Howarth 0 siblings, 2 replies; 31+ messages in thread From: Andreas Simbuerger @ 2010-08-11 22:34 UTC (permalink / raw) To: Joseph S. Myers; +Cc: gcc-graphite, gcc-patches 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 0/3] Configure support for official CLooG versions. 2010-08-11 22:34 ` Andreas Simbuerger @ 2010-08-11 23:39 ` Joseph S. Myers 2010-08-12 8:05 ` Andreas Simbuerger 2010-08-12 13:39 ` Jack Howarth 1 sibling, 1 reply; 31+ messages in thread From: Joseph S. Myers @ 2010-08-11 23:39 UTC (permalink / raw) To: Andreas Simbuerger; +Cc: gcc-graphite, gcc-patches 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 0/3] Configure support for official CLooG versions. 2010-08-11 23:39 ` Joseph S. Myers @ 2010-08-12 8:05 ` Andreas Simbuerger 2010-08-12 10:01 ` Joseph S. Myers 0 siblings, 1 reply; 31+ messages in thread From: Andreas Simbuerger @ 2010-08-12 8:05 UTC (permalink / raw) To: Joseph S. Myers; +Cc: gcc-graphite, gcc-patches 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 0/3] Configure support for official CLooG versions. 2010-08-12 8:05 ` Andreas Simbuerger @ 2010-08-12 10:01 ` Joseph S. Myers 2010-08-12 20:25 ` Andreas Simbuerger 0 siblings, 1 reply; 31+ messages in thread From: Joseph S. Myers @ 2010-08-12 10:01 UTC (permalink / raw) To: Andreas Simbuerger; +Cc: gcc-graphite, gcc-patches 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 0/3] Configure support for official CLooG versions. 2010-08-12 10:01 ` Joseph S. Myers @ 2010-08-12 20:25 ` Andreas Simbuerger 2010-08-13 15:01 ` Jack Howarth 0 siblings, 1 reply; 31+ messages in thread From: Andreas Simbuerger @ 2010-08-12 20:25 UTC (permalink / raw) To: Joseph S. Myers; +Cc: gcc-graphite, gcc-patches 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 0/3] Configure support for official CLooG versions. 2010-08-12 20:25 ` Andreas Simbuerger @ 2010-08-13 15:01 ` Jack Howarth 2010-08-13 16:09 ` Andreas Simbuerger 0 siblings, 1 reply; 31+ messages in thread From: Jack Howarth @ 2010-08-13 15:01 UTC (permalink / raw) To: Andreas Simbuerger; +Cc: Joseph S. Myers, gcc-graphite, gcc-patches 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 0/3] Configure support for official CLooG versions. 2010-08-13 15:01 ` Jack Howarth @ 2010-08-13 16:09 ` Andreas Simbuerger 2010-08-13 19:25 ` Sebastian Pop 0 siblings, 1 reply; 31+ messages in thread From: Andreas Simbuerger @ 2010-08-13 16:09 UTC (permalink / raw) To: Jack Howarth; +Cc: Joseph S. Myers, gcc-graphite, gcc-patches 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 0/3] Configure support for official CLooG versions. 2010-08-13 16:09 ` Andreas Simbuerger @ 2010-08-13 19:25 ` Sebastian Pop 0 siblings, 0 replies; 31+ messages in thread From: Sebastian Pop @ 2010-08-13 19:25 UTC (permalink / raw) To: Andreas Simbuerger Cc: Jack Howarth, Joseph S. Myers, gcc-graphite, gcc-patches 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 0/3] Configure support for official CLooG versions. 2010-08-11 22:34 ` Andreas Simbuerger 2010-08-11 23:39 ` Joseph S. Myers @ 2010-08-12 13:39 ` Jack Howarth 2010-08-12 18:52 ` Andreas Simbuerger 1 sibling, 1 reply; 31+ messages in thread From: Jack Howarth @ 2010-08-12 13:39 UTC (permalink / raw) To: Andreas Simbuerger; +Cc: Joseph S. Myers, gcc-graphite, gcc-patches 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 > ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 0/3] Configure support for official CLooG versions. 2010-08-12 13:39 ` Jack Howarth @ 2010-08-12 18:52 ` Andreas Simbuerger 2010-08-12 19:43 ` Jack Howarth 0 siblings, 1 reply; 31+ messages in thread From: Andreas Simbuerger @ 2010-08-12 18:52 UTC (permalink / raw) To: Jack Howarth; +Cc: Joseph S. Myers, gcc-graphite, gcc-patches 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 >> ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 0/3] Configure support for official CLooG versions. 2010-08-12 18:52 ` Andreas Simbuerger @ 2010-08-12 19:43 ` Jack Howarth 2010-08-13 16:09 ` Andreas Simbuerger 0 siblings, 1 reply; 31+ messages in thread From: Jack Howarth @ 2010-08-12 19:43 UTC (permalink / raw) To: Andreas Simbuerger; +Cc: Joseph S. Myers, gcc-graphite, gcc-patches 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 0/3] Configure support for official CLooG versions. 2010-08-12 19:43 ` Jack Howarth @ 2010-08-13 16:09 ` Andreas Simbuerger 2010-08-13 16:16 ` Jack Howarth 0 siblings, 1 reply; 31+ messages in thread From: Andreas Simbuerger @ 2010-08-13 16:09 UTC (permalink / raw) To: Jack Howarth; +Cc: Joseph S. Myers, gcc-graphite, gcc-patches 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 0/3] Configure support for official CLooG versions. 2010-08-13 16:09 ` Andreas Simbuerger @ 2010-08-13 16:16 ` Jack Howarth 2010-08-13 16:31 ` Andreas Simbuerger 0 siblings, 1 reply; 31+ messages in thread From: Jack Howarth @ 2010-08-13 16:16 UTC (permalink / raw) To: Andreas Simbuerger; +Cc: Joseph S. Myers, gcc-graphite, gcc-patches 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 0/3] Configure support for official CLooG versions. 2010-08-13 16:16 ` Jack Howarth @ 2010-08-13 16:31 ` Andreas Simbuerger 0 siblings, 0 replies; 31+ messages in thread From: Andreas Simbuerger @ 2010-08-13 16:31 UTC (permalink / raw) To: Jack Howarth; +Cc: Joseph S. Myers, gcc-graphite, gcc-patches 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* [PATCH 3/3] Support official CLooG.org versions. [not found] <cloog1> ` (2 preceding siblings ...) 2010-08-11 18:30 ` [PATCH 0/3] Configure support for official CLooG versions Andreas Simbürger @ 2010-08-11 18:45 ` Andreas Simbürger 3 siblings, 0 replies; 31+ messages in thread From: Andreas Simbürger @ 2010-08-11 18:45 UTC (permalink / raw) To: gcc-graphite; +Cc: gcc-patches, 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
end of thread, other threads:[~2010-08-23 16:39 UTC | newest] Thread overview: 31+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <cloog1> 2010-08-11 18:30 ` [PATCH 2/3] Fix include order to avoid failed compilation on CLOOG_ORG Andreas Simbürger 2010-08-11 21:01 ` Sebastian Pop 2010-08-11 18:30 ` [PATCH 1/3] Add necessary accessors for CloogMatrix (CLOOG_ORG) Andreas Simbürger 2010-08-11 20:54 ` Sebastian Pop 2010-08-11 18:30 ` [PATCH 0/3] Configure support for official CLooG versions Andreas Simbürger 2010-08-11 19:02 ` Sebastian Pop 2010-08-11 19:18 ` Jack Howarth 2010-08-11 19:27 ` Andreas Simbuerger 2010-08-11 21:55 ` Matthias Klose [not found] ` <2876_1281553691_4C62F51B_2876_2281_1_20100811190756.GB18599@bromo.med.uc.edu> 2010-08-11 19:23 ` Tobias Grosser 2010-08-12 6:14 ` Roberto Bagnara 2010-08-21 9:16 ` Gerald Pfeifer 2010-08-23 16:51 ` Richard Guenther 2010-08-11 19:08 ` Jack Howarth 2010-08-11 20:37 ` Andreas Simbuerger 2010-08-11 22:13 ` Joseph S. Myers 2010-08-11 22:34 ` Andreas Simbuerger 2010-08-11 23:39 ` Joseph S. Myers 2010-08-12 8:05 ` Andreas Simbuerger 2010-08-12 10:01 ` Joseph S. Myers 2010-08-12 20:25 ` Andreas Simbuerger 2010-08-13 15:01 ` Jack Howarth 2010-08-13 16:09 ` Andreas Simbuerger 2010-08-13 19:25 ` Sebastian Pop 2010-08-12 13:39 ` Jack Howarth 2010-08-12 18:52 ` Andreas Simbuerger 2010-08-12 19:43 ` Jack Howarth 2010-08-13 16:09 ` Andreas Simbuerger 2010-08-13 16:16 ` Jack Howarth 2010-08-13 16:31 ` Andreas Simbuerger 2010-08-11 18:45 ` [PATCH 3/3] Support official CLooG.org versions Andreas Simbürger
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).