From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13177 invoked by alias); 6 May 2009 21:24:23 -0000 Received: (qmail 13161 invoked by uid 22791); 6 May 2009 21:24:21 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-qy0-f126.google.com (HELO mail-qy0-f126.google.com) (209.85.221.126) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 06 May 2009 21:24:16 +0000 Received: by qyk32 with SMTP id 32so641405qyk.0 for ; Wed, 06 May 2009 14:24:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.76.144 with SMTP id c16mr3751317vck.17.1241645052035; Wed, 06 May 2009 14:24:12 -0700 (PDT) In-Reply-To: <1241644558.1711.26.camel@localhost> References: <1241644558.1711.26.camel@localhost> Date: Wed, 06 May 2009 21:55:00 -0000 Message-ID: <84fc9c000905061424n781ed1e7n419ffaf43cda2e9c@mail.gmail.com> Subject: Re: [graphite] Weekly phone call notes From: Richard Guenther To: Tobias Grosser Cc: GCC Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2009-05/txt/msg00174.txt.bz2 On Wed, May 6, 2009 at 11:15 PM, Tobias Grosser wrote: > Hi folks, hi graphities, > > here you are with the latest notes from our graphite phone call. > > It is also available on the wiki: > > http://gcc.gnu.org/wiki/Graphite_Phone_Call/2009_05_06 > > All the best > > Tobi > > > Attendees: Sebastian, Tobias, Christophe, Albert, Li, Jan, Razya, > Konrad, Antoniu > > =A0 =A0 =A0* Sebastian: > =A0 =A0 =A0 =A0 =A0 =A0 =A0* Working on IVstack removal, > =A0 =A0 =A0 =A0 =A0 =A0 =A0* Several other patches like "remove strcmp". = (Will be > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0committed as soon as possible) > =A0 =A0 =A0 =A0 =A0 =A0 =A0* in clast-to-gimple: > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* There is a problem finding t= he type of induction > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0variables and upper bound = expressions, as cloog > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0does not carry information= about them. > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* We will try = "unsigned long long" and > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0have to in= sert casts. (This might > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0trigger pr= oblems in the vectorizer and > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0might be s= low. Maybe we can optimize the > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0size of th= e iv later.) Before: Used we > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0used the t= ype of the old IV. But with > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0strip mini= ng there is no 1 to 1 relation > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0in between= ivs, so there is not always a > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0type. Othe= r idea: infer types from upper > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0and lower = bound expressions. But does > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0not seem t= o work either. This blocks the > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0work on re= moval IVSTACK. If the induction variables are only used to iterate over the domain then deriving them from upper and lower bounds (well - if you can constrain them) should be the right thing to do. In that context, when the IVs are then only used to index into arrays or used as offsets for pointers then using sizetype instead of unsigned long long would be a better default choice. Are there known constraints on the IV use? Like that operations on them never overflow? Richard. > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* Removal of IVStack: Blocked = by types. But > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0already triggers some bugs. > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* Reductions: Blocking by IVST= ack. > =A0 =A0 =A0* Li: > =A0 =A0 =A0 =A0 =A0 =A0 =A0* Mark loops as parallel with -fgraphite-force= -parallel > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(committed). > =A0 =A0 =A0 =A0 =A0 =A0 =A0* Trigger autopar with loop->can_be_parallel (= committed). > > =A0 =A0 =A0 =A0 =A0 =A0 =A0* Started testsuite for graphite_autopar (sent= for review > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0to gcc-patches). > =A0 =A0 =A0 =A0 =A0 =A0 =A0* > =A0 =A0 =A0 =A0 =A0 =A0 =A0* Autopar fails in graphite branch on this lin= e; > ------------------------------------------------------------------------ > red =3D reduction_phi (reduction_list, reduc_phi); > =A0 =A0 =A0if (red =3D=3D NULL) > =A0 =A0 =A0{ > =A0 =A0 =A0 =A0if (dump_file && (dump_flags & TDF_DETAILS)) > =A0 =A0 =A0 =A0 =A0fprintf (dump_file, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 " =A0FAILED: it is not a part of redu= ction.\n"); > =A0 =A0 =A0 =A0return false; > =A0 =A0 =A0} > ------------------------------------------------------------------------ > > =A0 =A0 =A0* Tobias: > =A0 =A0 =A0 =A0 =A0 =A0 =A0* Fix bugs to enable data reference building (= Now only > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0gfortran.dg/transpose_conjg_1.f90 fails). > =A0 =A0 =A0 =A0 =A0 =A0 =A0* Bootstrapped dependency testing. Worked exce= pt one test > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0case (gfortran.dg/cray_pointers_2.f90). > =A0 =A0 =A0 =A0 =A0 =A0 =A0* Working on his paper about the polyhedral pa= rt of > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0graphite to attract more research in this = area. > =A0 =A0 =A0 =A0 =A0 =A0 =A0* > =A0 =A0 =A0* Jan: > =A0 =A0 =A0 =A0 =A0 =A0 =A0* Got gcc summit paper accepted. Will be about= the design > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0of Graphite: IR, components of the Graphite > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0infrastructure, testsuite, example, intern= als, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0integration with external prototyping tool= s (POCC). We > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0should have some discussions about who des= cribes what in > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0graphite, as Tobias also has a paper accep= ted. > =A0 =A0 =A0 =A0 =A0 =A0 =A0* Worked on the translation of PCP to Polyhedr= al > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0representation. > >