This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: organization of optimization options in manual
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: Gary Funck <gary at intrepid dot com>, Sandra Loosemore <sandra at codesourcery 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: Tue, 20 Jan 2015 12:13:14 +0100
- 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> <54BD38FE dot 80701 at redhat dot com>
On Mon, Jan 19, 2015 at 6:03 PM, Jeff Law <law@redhat.com> wrote:
> On 01/17/15 07:34, Gary Funck 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 -O1 to -O2 and -O2 to -O3, that makes sense. However, -O0 to -O1 isn't
> something we can do this for right now as there are still many things that
> -O1 turns on that are not flag controlled.
>
> Whether or not to make all those bits individually controllable is a subject
> of debate. Personally, I think we have too many options, so my inclination
> would not be to make all those bits individually controllable. Others may
> have different opinions.
Also note that I'd like to go away from sharing the same pipeline with
-O1 and -O2 at least. -Og started this already (you can't turn on extra
passes in the -Og GIMPLE pipeline) and the -O1 "pipeline" doesn't
make much sense currently - I'd rather base -O1 on -Og or split it
away completely.
The issue here is that a single flag controls multiple instances of a pass,
and -O1 would still have things like -ftree-copy-prop but not run as many
times as -O2 (and -O1 currently).
For us developers I'd always envisioned to make our pass manager
scriptable and the pass pipeline being basically a script (so you
can even do things like iterating ... heh).
So I really really don't believe in the usefulness of 95% of the
optimization options we have (to a compiler user). And I'd rather
flag most of them as debugging ...
Richard.
> jeff
>