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.guent...@gmail.com>: > On Mon, Aug 13, 2012 at 9:39 PM, Igor Zamyatin <izamya...@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
