Re: [graphite] Cleanup of command line parameters

[Tobias Grosser <grosser at fim dot uni-passau dot de>]

Hi,

On Fri, 2008-10-10 at 23:31 +0200, Albert Cohen wrote:
> Tobias Grosser wrote
> > Hi graphities,
> > 
> > graphite consists of four flags "-floop-block", "-floop-interchange",
> > "-floop-stripmine" and "-fgraphite".
> > 
> > If any of these flags is set, we enable the graphite pass and we search
> > for SCoPs.
> > For every SCoP we try to apply transformations specified with
> > "-floop-block", "-floop-interchange" or "-floop-stripmine". But only if
> > we could apply a transformation, we replace the SCoP with new code
> > generated from the GRAPHITE data structures. Otherwise we do not touch
> > the GIMPLE representation.
> > If we only specify "-fgraphite", we never generate code for any SCoP, as
> > we never tried any transformation. So just using "-fgraphite" is
> > useless.
> > 
> > What is missing is a way to make GRAPHITE always generate code, even if
> > we did not apply any transformation.
> > 
> > This has two benefits:
> > - We can check the overhead the GIMPLE -> GRAPHITE -> GIMPLE
> > transformation costs.
> > - Wider test coverage, as we are able to run the code generator for
> > every SCoP, not only the SCoPs, we are able to transform.
> > 
> > 
> > Now:
> > ----
> > 
> > ï-fgraphite: Do nothing.
> > -floop-block, -floop-interchange, -floop-stripmine: Try these
> > transformations.
> > 
> > Only "-fgraphite":           Do nothing
> > Only "-floop-block":         Only loop blocked SCoPs are changed.
> > "-fgraphite -floop-block":   ïOnly loop blocked SCoPs are changed.
> > 
> > One solution: Reuse -fgraphite
> > ------------------------------
> > 
> > -fgraphite: Enable always code generation
> > -floop-block, -floop-interchange, -floop-stripmine: Try these
> > transformations.
> > 
> > Only "-fgraphite":           The identity transformation for all SCoPs.
> > Only "-floop-block":         Only loop blocked SCoPs are changed.
> > "-fgraphite -floop-block":   All SCoPs are are changed. Some SCoPs are
> > 			     loop blocked, others just the identity 
> > 			     transformation.
> > 
> > This allows us to get all the benefits but (mis)uses the -fgraphite
> > flag. At the moment it has no other meaning, but I could think of it
> > containing an automatic optimizer, that applies all available graphite
> > transformations or selects them automatically.
> > 
> > The other solution is: Use -fgraphite-identity
> > ----------------------------------------------
> > 
> > ï-fgraphite: Enable always code generation
> > -floop-block, -floop-interchange, -floop-stripmine, -fgraphite-identity:
> > Try these transformations.
> > 
> > Only "-fgraphite":           Do nothing. Free for later use.
> > Only "-floop-block":         Only loop blocked SCoPs are changed.
> > Only "-fgraphite-identity":  The identity transformation for all SCoPs.
> > "-fgraphite-identity
> >  -floop-block":              All SCoPs are are changed. Some SCoPs are
> > 			     loop blocked, others just the identity 
> > 			     transformation.
> > 
> > This makes sense, as we only generate code for applied and enabled
> > transformations. These are loop-blocking, interchange, stripmine and
> > - may be - the new and very easy to write identity transformation, that
> > does nothing, but enable code generation.
> > 
> > What du you think about these different solutions?
> 
> Hi Tobias,
> 
> I am in favor of prefixing all transformation passes with -fgraphite-
> leading to -fgraphite-block -fgraphite-stripmine -fgraphite-identity and 
> the new ones to come. These flags should probably disappear at some 
> point, as a more unified optimization heuristic should arise that 
> combines all transformations, with some parameters to influence the 
> profitability heuristic.
> 
> I agree -fgraphite should be reserved for later use, but not mandatory 
> to use any of the new -fgraphite-xxx options.
> 
> This is just a suggestion with a partial understanding of the option 
> naming scheme in GCC only!

I see what you mean. For me all the graphite flags seem to be like
temporary flags, as the idea of the polyhedron model is to allow a lot
of different optimizations, that can not be split up to loop blocking 
So in this case the current flags seem for me to just enable different
demo/test optimizers in graphite, that are replaced later by a better
general one. So I like your idea.

I will submit a patch containing this idea.

See you
Tobias