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


On Fri, Oct 10, 2008 at 8:54 PM, Tobias Grosser
<grosser@fim.uni-passau.de> wrote:
> On Fri, 2008-10-10 at 20:35 +0200, Manuel LÃpez-IbÃÃez wrote:
>> 2008/10/10 Tobias Grosser <grosser@fim.uni-passau.de>:
>> >
>> > Now:
>> > ----
>> >
>> > ï-fgraphite: Do nothing.
>> > -floop-block, -floop-interchange, -floop-stripmine: Try these
>> > transformations.
>>
>> This only applies to the branch, does it? There is no do-nothing
>> command-line option in trunk, is there?
>
> No, that's the same for trunk. But it seems my description was not that
> clear. In fact "-fgraphite" does a lot.
>
> If you enable "-fgraphite" the complete CFG graph is scanned and we
> generate the GRAPHITE representation for every SCoP. This is great to
> make compile tests for the transformation from GIMPLE to GRAPHITE. So
> e.g. the polyhedron test suite can be transformed to GRAPHITE, without
> any failure. And most of the SPEC test suite also.
>
> But we only generate GIMPLE out of GRAPHITE, if we applied a
> transformation. This was thought to reduce compile time, as we do not
> regenerate code for SCoPs, that never changed.
>
> If you want to test a graphite transformation, use "-floop-block" (The
> one implemented and used for testing).
>
> What I would like to discuss (and later implement) is how we could allow
> to specify a identity transformation, that enables code generation for
> all SCoPs. This transformation would probably require higher compile
> time and generate slower code, but can be used to test the GRAPHITE code
> generation better.
>
> But as you see in my description, I would also like to change the
> meaning of -fgraphite.
>
> Solution one would make it to generate the identity transformation.
> Solution two would make it an automatic optimizer (yet unimplemented),
> that could at the moment default to all available graphite
> transformations.

For 4.4 I would like us to not expose -fgraphite to the user, as it will only
generate bugreports and never be profitable for them.  If you think it makes
sense to have the -fgraphite debugging only then you can add a new option
for debugging as you suggested - but I think -fgraphite can as well
always generate
code to be a more useful debugging option?

So, can we for 4.4 remove the -fgraphite option (or at least its
user-level documentation)
as well as -floop-stripmine?

Thanks,
Richard.

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