Re: RFA: MN10300: Add AM34 target and scheduling

[Jeff Law <law at redhat dot com>]

 On 10/28/10 02:03, Nick Clifton wrote:
> Hi Jeff,
>
> > I'd really like to see some further analysis of the circumstances that
> > lead to the spill failure on the mn103.
>
> Fair enough - I was being lazy by not investigating further.  Taking 
> 20021120-3.c as my test case, here is what happens.  Before the first 
> scheduling pass we have:
>
> (insn  3 (set (reg:SI 64 [ x ]) (reg:SI d1 [ x ]))
>
> (insn  4 (set (reg:SI 65 [ y ]) (mem/c/i:SI (plus:SI (reg:SI ap) 
> (const_int 12))
>
> (insn  9 (set (reg:SI 68)  (udiv:SI (reg/v:SI 64 [ x ]) (reg/v:SI 65 [ 
> y ])))
>          (set (reg:SI 69)  (umod:SI (reg/v:SI 64 [ x ]) (reg/v:SI 65 [ 
> y ])))
>
> (insn 10 (set (mem:SI (plus:SI (reg:SI sp) (const_int 12)) (reg:SI 68))
>
> (insn 12 (set (reg:SI d1)  (symbol_ref:SI ("*.LC0")
>
> (call 13 (set (reg:SI d0)  (call (mem:QI (symbol_ref:SI ("sprintf")))))
>
>
> After the scheduling pass this becomes:
>
>
> (insn  3 (set (reg:SI 64 [ x ])  (reg:SI d1 [ x ]))
>
> (insn  4 (set (reg:SI 65 [ y ])  (mem:SI (plus:SI (reg:SI ap) 
> (const_int 12))
>
> (insn 12 (set (reg:SI d1)  (symbol_ref:SI ("*.LC0")))
>
> (insn  9 (set (reg:SI 68)  (udiv:SI (reg:SI 64 [ x ]) (reg:SI 65 [ y ])))
>          (set (reg:SI 69)  (umod:SI (reg:SI 64 [ x ]) (reg:SI 65 [ y ])))
>
> (insn 10 (set (mem:SI (plus:SI (reg:SI sp) (const_int 12)) (reg:SI 68))
>
> (call 13 (set (reg:SI d0)  (call (mem:QI (symbol_ref:SI ("sprintf")
>
>
> Note how insn 12 has been moved before insn 9.  This means that both 
> d0 and d1 are now live at insn 9, and hence there are insufficient 'd' 
> registers to spill.
>
> I am not sure how to correct this though.  Any suggestions ?
This is exactly the kind situation I was concerned about -- this 
indicates that scheduling, at least on the base mn103 is simply not 
going to be safe.  My first concern was the return value copy from d0 
into a pseudo and lengthening that lifetime, the second (but unstated 
concern) was argument register setup.


THe divmod requires the entire d0/d3 register set, but scheduling is 
capable of moving arg setup across the divmod insn which sets up a 
situation where d0/d1 are live across the divmod and can't with our 
current reload implementation be spilled.

So, the way to go is to completely eliminate scheduling on the base 
mn103 port, it's simply not going to be safe.

Jeff