Fix instability of -fschedule-insn for x86

Yuri Rumyantsev ysrumyan@gmail.com
Tue Sep 18 10:48:00 GMT 2012


Hi All,

This patch aims to fix all stability issues related to using the first
scheduler in gcc
for x86 target (there several reported issues related to this problem).

Main idea of this activity is mostly to provide user a possibility to
safely turn on first scheduler for his codes. In some cases this could
positively affect performance, especially for in-order Atom.

Below is short description of proposed changes.

Main idea of this patch is to restrict code motion of instructions
having likely spilled HW registers as their operands - in general
all these instructions are unloading of incoming function argument
in the function entry and passing of outgoing function arguments.
This is essential for correct scduling since live range of such insns
is not defined before register allocation pahse.
This done through 2 hooks:

1. ix86_adjust_priority which sets up the priority of moves from
likely spilled HW registers to maximum that allows us to schedule
such insns as soon as possible, i.e. all moves correspondent to
incoming function arguments will be scheduled at the top of
function entry and moves correspondent to function return
value will be scheduled immediately after call.
2. ix86_dependencies_evaluation_hook which insert additional
dependencies for outgoing function arguments passed in likely
spilled HW registers to avoid their code motion. This is done
through the following steps:
- scan the current schedule region to find all call instructions in
  reverse order;
- find out the first argument that passed in likely spilled HW
  register. Starting from it insert output dependency between it and
  possible previous argument (it does not matter if it passed in likely
  spilled register or not). This is done in add_parameter_dependencies;
  after it all arguments starting from the first one that is passed in
  likely spilled register are pairwise connected through output
  dependency.
- add dependencies to the first function argument on
  the rest of instructions in the current block (until next call)  to avoid
  intra block code motion.
- to avoid possible interblock code motion we also check if the first
  argument has dependee in another blocks and if so insert dependency to
  the last non-jump set instruction.

This patch was deeply tested on Atom (eembc_2_0, spec2000 in base/peak mode)
 and Big Core (spec2006 in base/peak mode).
Also gcc full bootstrapping with turned on 1st scheduler by default was done.

Tested for i386 and x86-64, ok for trunk?

ChangeLog:

2012-09-18  Yuri Rumyantsev  <ysrumyan@gmail.com>

	* config/i386/i386.c (ix86_dep_by_shift_count_body) : Add
	check on reload_completed since it can be invoked before
	register allocation phase in 1st scheduler.
	(ia32_multipass_dfa_lookahead) : Do not use dfa_lookahead for 1st
	Scheduler to save compile time.
	(ix86_sched_reorder) : Do not perform ready list reoddering for 1st
	Scheduler to save compile time.
	(insn_is_function_arg) : New function. Returns true if lhs of insn is
	HW function argument register.
	(add_parameter_dependencies) : New function. Add output dependencies
	for chain of function adjacent arguments if only there is a move to
	likely spilled HW registers. Return first argument if at least one
        dependence was added or NULL otherwise.
	(avoid_func_arg_motion) : New function. Add output or anti dependency
	from insn to first_arg to restrict code motion.
	(add_dependee_for_func_arg) : New function. Avoid cross block motion of
	function argument through adding dependency from the first non-jump
	insn in bb.
	(ix86_dependencies_evaluation_hook) : New function. Hook for schedule1:
	avoid motion of function arguments passed in passed in likely spilled
	HW registers.
	(ix86_adjust_priority) : New function. Hook for schedule1: set priority
	of moves from likely spilled HW registers to maximum to schedule them
	as soon as possible.
	(ix86_sched_init_global): Do not perform multipass scheduling for 1st
	Scheduler to save compile time.



More information about the Gcc-patches mailing list