This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: What is exactly in O2?
On Wed, 31 Jan 2001 17:42:21 -0500, Michael Meissner said:
> On Wed, Jan 31, 2001 at 05:33:42PM -0500, Phil Edwards wrote:
> >
> > Answering your questions in reverse order:
> >
> > > A subsidiary question if this is the right place to ask this kind of questions.
> >
> > Sure.
> >
> > > I would like to learn how can I determine exactly the set of compile flags who
> > > are triggered by O2.
> >
> > If you want an /exact/ answer you have to go to the source. In this case,
> > a good place to start is gcc/toplev.c, around line 4600. There you will
> > find the logic that eventually includes (among other things):
> >
> > flag_optimize_sibling_calls = 1;
> > flag_cse_follow_jumps = 1;
> > flag_cse_skip_blocks = 1;
> > flag_gcse = 1;
> > flag_expensive_optimizations = 1;
> > flag_strength_reduce = 1;
> > flag_rerun_cse_after_loop = 1;
> > flag_rerun_loop_opt = 1;
> > flag_caller_saves = 1;
> > flag_force_mem = 1;
> > flag_peephole2 = 1;
> > #ifdef INSN_SCHEDULING
> > flag_schedule_insns = 1;
> > flag_schedule_insns_after_reload = 1;
> > #endif
> > flag_regmove = 1;
> > flag_strict_aliasing = 1;
> > flag_delete_null_pointer_checks = 1;
> > flag_reorder_blocks = 1;
> >
> > There are some others as well from the -O1 setting, plus any platform-
> > dependant tweaks.
> >
> > Somewhere I have a patch to allow a -print-flags switch to the compiler,
> > which will parse all the other command-line switches and then print the
> > flag_* variables which get changed. It's useful for this kind of thing,
> > e.g., "-O2 -print-flags". If you would this useful I'll mail it to you.
>
> Even without -print-flags you can get this information via two methods:
>
> -v -Q (answer in stderr output)
> -fverbose-asm -save-temps (answer in <file>.s)
> -fverbose-asm -S (answer in <file>.s)
>
> Note, the flags set by -O2 will change over time.
>
> In terms of i386 vs. i686, things that come to mind:
>
> 1) The optimal alignment padding rules are different between the two.
>
> 2) Instruction selection is different between the two, based on which
> instructions are faster on the machine selected. For example, in the
> 386, if a function is called with an argument that is in memory, the
> compiler will generate a single push operation from memory, while for
> the 686, it will generate a load and then a push. In some cases this
> can cause other code to be different as it spills something else that
> lived in a register to the stack.
>
Yes but the fact is ran both executrables on a PII/400 and then on a PIII/667. Logically the one compiled with arch=i686 should have crushed the one with cpu=i386. In this particular program it was the opposite so we are left with three hypotheses
1) The optimizer does not a good job when compiling with arch=i686
2) The optimizer optimizes for PPro but seemingly minor differences in architecture between PPro and newer P6-family processors caused big performance hits. Since PPro is dead it would make sense to have the code select what is good for
PII/PIII/celeron instead of PPro.
3) O2 plus cpu=386 triggers a flag who has spectacular effects on this particular
program and it is not triggered by O2 plus cpu=386.
The fact that additional flags have the arch=i686 program become suddenly much faster points towards the third hypotheses.
JFM