This is the mail archive of the
mailing list for the GCC project.
Re: criteria.html open issues
- To: dewar at gnat dot com
- Subject: Re: criteria.html open issues
- From: "Zack Weinberg" <zackw at Stanford dot EDU>
- Date: Mon, 28 May 2001 08:27:50 -0700
- Cc: acahalan at cs dot uml dot edu, gcc at gcc dot gnu dot org
On Mon, May 28, 2001 at 08:24:26AM -0400, email@example.com wrote:
> <<We'd want to look at tradeoffs between execution speed, executable
> size, compiler speed, and ease of debugging; I'd suggest abandoning
> the idea of 'levels of optimization' and instead tell the compiler
> what you want to optimize for.
> I disagree, you need reasonable defaults. Most programmers don't know enough
> to understand what various optimizations do, or rather what their subtle
> effects are when you take all the factors into effect (for instance most
> programmers would not understand exactly what the issues are for loop
> unrolling). Yes, you can ask programmers to experiment, and they will and
> should if they need to extract max performance from a given appl, but it
> is very useful to have general defaults.
I didn't mean to imply that there shouldn't be defaults, only that
categorizing optimizations by _levels_ isn't useful. Keep -O and/or
-O2 by all means, but let's not have -O3, -O4, ... -O9 the way some
vendor compilers do. I might even suggest eliminating -O1 (make -O
synonymous with -O2). It's never been clear what the difference is in
terms of the tradeoffs I mentioned.
I was also not thinking of forcing people to specify all the details.
We already have the -f options for that. More like -Ospace, -Ofast,
-Odebug (easy debugging, but don't generate crap code the way -O0
[Note to the audience: at present -On for n>3 has exactly the same
effect as -O3 and this is unlikely to change.]
zw A man who has never gone to school may steal from a freight car, but if he
has a university education, he may steal the whole railroad.
-- Theodore Roosevelt