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, 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.
--
Michael Meissner, Red Hat, Inc. (GCC group)
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work: meissner@redhat.com phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org fax: +1 978-692-4482