On Fri, Oct 10, 2008 at 11:31 PM, Albert Cohen <[EMAIL PROTECTED]> 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. >
Note that we cannot really remove switches from the user, but we have to at least keep them as no-op for backward compatibility. Which is why I would like you to think twice at least as to what options you want to add for 4.4. As a rule of thumb, do not add (or at least document) options that are not useful for users of GCC but only developers of GCC. Maybe you can add a glob for debugging options with -fdebug-graphite-XXX instead? Thanks, Richard. > 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! > > Albert >
