On Wed, May 6, 2009 at 11:15 PM, Tobias Grosser
<gros...@fim.uni-passau.de> 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
>
>      * Sebastian:
>              * Working on IVstack removal,
>              * Several other patches like "remove strcmp". (Will be
>                committed as soon as possible)
>              * in clast-to-gimple:
>                      * There is a problem finding the type of induction
>                        variables and upper bound expressions, as cloog
>                        does not carry information about them.
>                              * We will try "unsigned long long" and
>                                have to insert casts. (This might
>                                trigger problems in the vectorizer and
>                                might be slow. Maybe we can optimize the
>                                size of the iv later.) Before: Used we
>                                used the type of the old IV. But with
>                                strip mining there is no 1 to 1 relation
>                                in between ivs, so there is not always a
>                                type. Other idea: infer types from upper
>                                and lower bound expressions. But does
>                                not seem to work either. This blocks the
>                                work on removal 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.

>                      * Removal of IVStack: Blocked by types. But
>                        already triggers some bugs.
>                      * Reductions: Blocking by IVSTack.
>      * Li:
>              * Mark loops as parallel with -fgraphite-force-parallel
>                (committed).
>              * Trigger autopar with loop->can_be_parallel (committed).
>
>              * Started testsuite for graphite_autopar (sent for review
>                to gcc-patches).
>              *
>              * Autopar fails in graphite branch on this line;
> ------------------------------------------------------------------------
> red = reduction_phi (reduction_list, reduc_phi);
>      if (red == NULL)
>      {
>        if (dump_file && (dump_flags & TDF_DETAILS))
>          fprintf (dump_file,
>                   "  FAILED: it is not a part of reduction.\n");
>        return false;
>      }
> ------------------------------------------------------------------------
>
>      * Tobias:
>              * Fix bugs to enable data reference building (Now only
>                gfortran.dg/transpose_conjg_1.f90 fails).
>              * Bootstrapped dependency testing. Worked except one test
>                case (gfortran.dg/cray_pointers_2.f90).
>              * Working on his paper about the polyhedral part of
>                graphite to attract more research in this area.
>              *
>      * Jan:
>              * Got gcc summit paper accepted. Will be about the design
>                of Graphite: IR, components of the Graphite
>                infrastructure, testsuite, example, internals,
>                integration with external prototyping tools (POCC). We
>                should have some discussions about who describes what in
>                graphite, as Tobias also has a paper accepted.
>              * Worked on the translation of PCP to Polyhedral
>                representation.
>
>

Reply via email to