Re: Merging Graphite to trunk

[Sebastian Pop <sebpop at gmail dot com>]

On Fri, Jul 31, 2009 at 04:08, Richard Guenther<rguenther@suse.de> wrote:
>> We do perform optimizations with this option, at least the following:
>> - index splitting: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35356
>> - dead code elimination:
>> http://groups.google.com/group/gcc-graphite/browse_thread/thread/4efde0116c50716e
>> - minimization of control flow conditions.
>
> Ah, ok. ÂCan you add these three things to the documentation?
>

These are already in the original patch:

@item -fgraphite-identity
@opindex fgraphite-identity
Enable the identity transformation for graphite.  For every SCoP we generate
the polyhedral representation and transform it back to gimple.  Using
@option{-fgraphite-identity} we can check the costs or benefits of the
GIMPLE -> GRAPHITE -> GIMPLE transformation.  Some minimal optimizations
are also performed by the code generator CLooG, like index splitting and
dead code elimination in loops.

>> Both: -fgraphite-force-parallel uses the data dependence analysis of
>> Graphite to detect parallel loops and uses tree-parloops.c to code
>> generate the parallel code.
>
> I see. ÂI am trying to second-guess if -ftree-parallelize-all-loops
> wouldn't make more sense as an option here (I guess the user doesn't
> care at all if it uses graphite under the hood or not ...).
>

This is correct.  But I don't see it happen in general for the flags
of GCC: even the flag that you propose contains "tree" that would be
useless information for a user of GCC.  At least when you have
graphite in the name you know that you need Graphite to use it.  Again
this is not consistent as we now have -floop-block, -floop-strip-mine,
and -floop-interchange.  These last flags have, in my opinion, much
better names.

Sebastian