This is the mail archive of the 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 [PATCH]


On Sun, 2008-10-12 at 13:19 +0200, Tobias Burnus wrote:
> Hi,
> Tobias Grosser wrote:
> > another patch. It contains:
> > 
> > - Removal of documentation outside of common.opts for (-fgraphite,
> >   -floop-block, -floop-interchange, -floop-strip-mine)
> >   This means doc/invoke.texi.
> >   (Proposed by Richi)
> While I agree that -fgraphite does not make sense as user option, I'm
> not sure about -floop-block and -floop-interchange. I could imagine that
> some users would like to play with this option (though I have no real
> opinion about this).

The problem I see is, that these options are for me like intermediate
demonstration options, as graphite should get an automatic optimizer. So
I am not sure what to do. I see these options:

1. Keep them until we have these optimizer:

Here we have the problem what to do after that. We could simply ignore
them or we make them like hints to allow the optimizer trying specific
transformations. But I think, it may not even be possible to try to
disable specific optimizations in all cases while using the polytop
So we may have options just used in one or two releases.

2. Keep them like the -fgraphite options hidden, but allow interested
user to try graphite. So we get interested testers, but do not have to
keep these - maybe later misleading - options forever.

> > - Removal of flag "-floop-strip-mine", as it never will improve 
> >   performance and so there will be no use for it.
> >   (Proposed by Harsha)
> I might have misunderstood Harsha, but I think he said that it only does
> not improve the performance if used by itself, i.e. combined with other
> options it is/might be profitable. Thus one may leave it in as
> undocumented option. (I have no opinion about this and I did no tests, I
> only wanted to stress the "by itself".)

No I am quite sure, we do not need this flag. Yes you are right strip
mining can help combined with loop interchange to improve performance.
But this is -floop-block and already available.

> In any case, those changes should also be documented at
>, which currently lists all options.
> Tobias B

Thanks for your comments and please correct me, if I said something
wrong/could say something better. I am quite new to the gcc development
so every hint is appreciated. 

see you


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