RE: [graphite] Cleanup of command line parameters

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

On Fri, 2008-10-10 at 13:49 -0500, Jagasia, Harsha wrote:
> Hi Tobias,
> >
> >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.
> >
> >
> 
> I think this is a good idea in the long run (in the 4.5 timeframe). My only issue with it is that we have several bugs today even without generating code unless a transformation is picked. Of cpu2006 benchmarks, all but 4 fail to build. We have memory leak issues, we have not tried to bootstrap gcc with graphite enabled. I think that expanding the coverage or overhead testing only makes sense after we have fixed the existing bugs.
> I personally like the "-fgraphite-identity" approach the best.
Hi Harsha,

I understand your position and I do not want to extend the graphite
behavior, that we get more bugs. I think at the moment the most
important part we need for graphite is stable code for the front and
backend, that we can test on Polyhedron, SPEC and gcc.
So I would like to see this proposal as a step backwards. Just add a
transformation, that does nothing (instead of loop blocking) to test the
backend.
This will simplify debugging of the existing backend bugs, and will stop
us from committing new bugs, that are hidden by the limited test
coverage.

My dream would be nightly runs of polyhedron, spec and gcc with
-fgraphite-identity to be able to fix the existing bugs.

See you
Tobi