This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]