[PATCH][RFC] Fixing instability of -fschedule-insns for x86

Yuri Rumyantsev ysrumyan@gmail.com
Tue Aug 14 11:51:00 GMT 2012


Hi Richard,

These changes try to resolve the known problem with the first
instruction scheduler for x86 platform. The main issue is the
existence of hardware registers that are used for unloading of
function arguments passing in HW registers and for passing function
arguments in HW registers.
1. Unloading HW function argument registers.
To prevent hoisting of instructions with virtual registers having
bigger priority before unloading function arguments that may lead to a
register spill problem in Register Allocation phase (all HW registers
are busy) we set up the max priority all moves from function argument
HW registers through ix86_adjust_priority hook. It means that all such
instructions will be scheduled at the beginning of function.
2. Passing function arguments in HW registers.
The main problem here is that backward copy propagation phase (aka
combine instructions) can propagate HW argument registers to
instructions evaluating argument values (e.g.  issue#46829). To
resolve this problem I decided to preserve an order of instructions
writing to HW function argument registers through additional output
dependencies between two adjacent instructions
(ix86_dependencies_evaluation_hook).

Hope my short explanation will help you to review my changes.

Best regards.
Yuri.


2012/8/14 Richard Guenther <richard.guenther@gmail.com>:
> On Mon, Aug 13, 2012 at 9:39 PM, Igor Zamyatin <izamyatin@gmail.com> wrote:
>> Hi all!
>>
>> Patch aims to fix instability introduced by first scheduler on x86. In
>> particular it targets following list:
>>
>> [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46843
>> [2] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46829
>> [3] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36680
>> [4] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42295
>>
>> 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.
>>
>> It would be great to hear some feedback from the community about the change.
>
> Maybe you can elaborate on this change?  It's hard to reverse engineer
> what you try to do from the patch alone.
>
> Richard.
>
>> Thanks in advance,
>> Igor



More information about the Gcc-patches mailing list