This is the mail archive of the
mailing list for the GCC project.
Re: organization of optimization options in manual
- From: Sandra Loosemore <sandra at codesourcery dot com>
- To: Joel Sherrill <joel dot sherrill at oarcorp dot com>
- Cc: Gary Funck <gary at intrepid dot com>, Jeff Law <law at redhat dot com>, GCC Development <gcc at gcc dot gnu dot org>, Gerald Pfeifer <gerald at pfeifer dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>
- Date: Sat, 17 Jan 2015 13:13:23 -0700
- Subject: Re: organization of optimization options in manual
- Authentication-results: sourceware.org; auth=none
- References: <54B70059 dot 3030808 at codesourcery dot com> <54B736E8 dot 70406 at redhat dot com> <54B75A61 dot 5070102 at codesourcery dot com> <54B75B1F dot 3070308 at redhat dot com> <20150117143404 dot GA13533 at intrepid dot com> <C0E305C1-F659-478D-8F47-23D697A3D9BD at oarcorp dot com>
On 01/17/2015 11:30 AM, Joel Sherrill wrote:
On January 17, 2015 8:34:04 AM CST, Gary Funck <email@example.com> wrote:
On 01/14/15 23:15:59, Jeff Law wrote:
Sounds good. I think just starting with the list & creating the
with the list. Then post here and we'll iterate and try to nail that
before you start moving everything in the .texi file.
Something to consider, if the optimization options are re-worked:
Arrange the -O options such that -O1 can be described by a
distinct set of specific optimizations enabled (or disabled)
in addition to -O0, and -O2 would be described as a composite
of specific optimizations applied to -O1 and so on. (This
might require the addition of new optimization options.)
For completeness, if a specific optimization requires
certain passes or the assertion of other options, that should
somehow be encoded internally within the compiler.
This would potentially make it easier to find which optimization
(or pass) is causing a regression and might make it easier
for users to understand the exact effect of a particular -O option.
Make sure whatever pattern is followed for optimizations is followed for warnings. It is nice to know when adding an option actually is needed.
While there are a lot of things that can be done to improve the
organization of the manual, I'm thinking it's a better strategy to make
improvements incrementally rather than trying to come up with a grand
plan to be implemented all at once. (In particular, I have some spare
cycles to work on this right now, but I can't predict how long that
situation will last.)
My plan for what's being discussed in this thread was just to move the
existing documentation around, add new subsection structure, and cons up
an introductory paragraph for each new section -- not rewrite any of the
existing documentation, or touch anything in other sections.
BTW, as a GCC user I'm also very frustrated by the (lack of)
organization in the extensions chapter; the information about attributes
and built-in functions is all mixed up with sections on random syntactic
extensions like "Dollar Signs in Identifier Names", etc. Maybe somebody
else could work on a proposal for reordering the material in that
chapter in parallel?