This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: VTA merge - cmdline
Gerald Pfeifer wrote:
> On Tue, 9 Jun 2009, Alexandre Oliva wrote:
>> If --param is to be used for things other than constants to control the
>> amount of optimization, its documentation must adjusted to reflect this,
>> and moved where it belongs.
> I believe that indeed the documentation is not accurate and should be
> adjusted and that indeed --param does/should not only guide optimizations.
> That may have been the original usecase, but Mark's explanation matches my
> understanding and memory, too.
I agree. Yes, --param was originally about optimization, but I believe
that it should be used for magic constants which are not intended to
affect the behavior of the generated code, including the speed at which
it runs, the space which it consumes, and so forth. My view is that
--param is for the most advanced users -- including GCC developers
debugging the compiler; these are things that could well be hard-wired
into the compiler, but we have made them dynamic to make it easier to do
tuning experiments and such.
To my mind, the fact that dump options are the "-f" namespace is a
mistake, though probably one that we cannot change at this point. It
would be nice if the option's form indicated what kind of option it was:
fine-tuning of the language accepted/implemented (e.g.,
-fno-exceptions, -fuse-cxa-atexit), optimization (e.g., -fno-sched2), or
dump (-fdump-tree...). But, I think that ship has sailed.
Still, we should try not to throw more random noise into "-f" than
necessary. That will make it easier for users to find the options they
want.
--
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713