Re: More ARM scheduling weirdness

[Richard Earnshaw <rearnsha at arm dot com>]

law@cygnus.com said:
> Yea, I hacked on it a little more here and added load & mult.  I
> didn't think store1 was needed, but I could certainly be wrong. 

I've just committed a patch to the new arm/thumb backend to add "type" 
attributes for thumb instructions and to add two new rules to the "core" 
unit.

The first is a rule that adds a single cycle in core for all insns with 
the attribute "core_cycles" == "single" (note we already had this 
attribute, but weren't making use of it -- that makes me think that 
missing this rule out of the schedule must have been an oversight); the 
other rule adds a catch-all rule for all wierdo insns that take multiple 
cycles but don't have a special rule for the unit.  The most significant 
class in this latter category is calls -- It seems to me that there is no 
point trying to schedule delays after a call insn based on what we were 
doing before we took the call.  Consider

(insn (set (reg:DF f4) (div:DF (reg:DF f0) (reg:DF f1))))

(call_insn (call (symbol_ref 'foo')))

(insn (set (mem:DF (addr)) (reg:DF f4)))

The division unit in the FPA isn't the fastest in the world...

It doesn't seem to be sensible to schedule the store way after the call, 
since the call will probably either stall the division anyway (by trying 
to use the set register, or take sufficiently long to execute that the 
result is ready by the time we get back.

I've also added a cost adjustment in arm_adjust_cost to kill the cost of a 
read-after-write dependency if the following insn is a call.

This isn't perfect, but it looks like it gives better schedules than 
before.