This is the mail archive of the gcc@gcc.gnu.org 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]

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

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