This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: organization of optimization options in manual

On Mon, Jan 19, 2015 at 6:03 PM, Jeff Law <> 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 ...


> jeff

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]