organization of optimization options in manual

Sandra Loosemore sandra@codesourcery.com
Sat Jan 17 20:13:00 GMT 2015


On 01/17/2015 11:30 AM, Joel Sherrill wrote:
>
>
> On January 17, 2015 8:34:04 AM CST, Gary Funck <gary@intrepid.com> wrote:
>> On 01/14/15 23:15:59, Jeff Law wrote:
>>> Sounds good.  I think just starting with the list & creating the
>> buckets
>>> with the list.  Then post here and we'll iterate and try to nail that
>> down
>>> 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.
>
>> - Gary
>
> --joel

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?

-Sandra




More information about the Gcc mailing list