This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
RE: [graphite] Cleanup of command line parameters
- From: "Jagasia, Harsha" <harsha dot jagasia at amd dot com>
- To: "Tobias Grosser" <grosser at fim dot uni-passau dot de>, "GCC" <gcc at gcc dot gnu dot org>
- Date: Fri, 10 Oct 2008 13:49:20 -0500
- Subject: RE: [graphite] Cleanup of command line parameters
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.
Thanks,
Harsha
>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?
>
>See you
>Tobi
>