Re: scheduler fix for small register classes

[Ian Lance Taylor <iant at google dot com>]

Alexandre Oliva <aoliva@redhat.com> writes:

> While working with Glauber on TLS improvements for ARM, we've come
> across a problem in the scheduler.  Even though the scheduler is
> careful enough to not extend the life of CLASS_LIKELY_SPILLED_P
> classes before reload, to avoid problems such as moving the
> instruction that sets the return value before other instructions that
> might need that hardware register, it does nothing to avoid extending
> the life of hardware registers holding incoming arguments.  Even
> though combine avoids substituting such hardware registers, schedule
> might still move the copies from the hardware registers to pseudos,
> emitted before the function begin note, past instructions that might
> require such hardware registers, and then reload loses.
> 
> This patch fixes this problem, by arranging for the function begin
> note to be a scheduler move barrier before reload, thus avoiding the
> harmful rearrangement.
> 
> Bootstrapped and tested on amd64-linux-gnu native and cross to
> arm-linux-gnu, with a patch that modifies SMALL_REGISTER_CLASSES in
> arm.h so as to be defined to 1, and introduces a register class
> containing only r0, as well as a number of TLS-related instructions
> that use the new class.

It seems to me that there is a general problem here, which is that on
some machines, before reload, a MEM may depend upon specific hard
registers.  Your patch fixes the most common case of that, copying
parameters in hard registers to pseudo-registers at the start of a
function, but it seems to me that there are other possible cases as
well, such as when copying arguments to hard registers before a
function call.

I think it might be better to change sched-deps so that before reload
is introduces a dependency between any hard register that is
CLASS_LIKELY_SPILLED_P and any MEM.  That is, before reload treat a
MEM read or write as a write of any register which is
CLASS_LIKELY_SPILLED_P.  I note that you can find all such registers
in the HARD_REG_SET losing_caller_save_reg_set, although that should
be renamed before trying to use it in sched-deps.c.

Or I'm certainly open to other approaches.  Besides the fact that this
may be a general problem, I think we should try to move in the
direction of representing explicit dependencies rather than relying on
magic instruction notes.

Ian