Re: More ARM scheduling weirdness

[Jeffrey A Law <law at cygnus dot com>]

  In message <199910270952.KAA03486@cam-mail1.cambridge.arm.com>you write:
  > 
  > law@cygnus.com said:
  > > (define_function_unit "core" 1 0
  > >   (and (eq_attr "ldsched" "yes") (eq_attr "type" "!store2,store3,store4
  > > ")) 1 1) 
  > 
  > 
  > Hmm, thinking about this, I don't see why this should be disabled if not 
  > doing load scheduling, surely the rule should be more like
  > 
  > (define_function_unit "core" 1 0
  >   (eq_attr "type" "!load,mult,store1,store2,store3,store4") 1 1)
  > 
  > Note I've added load and mult to the list, both of these are already 
  > handled by another rule.
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.

  > What happens if an insn matches more than one rule for the same unit?
I originally thought you'd get the worst-case assumptions, but I I'm no longer
sure after some of the stuff I saw earlier today.  I'm starting to wonder if
it's order dependent.  I guess I could wander the docs & code to see if it's
documented one way or the other.

On the subject of re-thinking how we describe this stuff for the ARM.  Yes,
I've thought about it.  But I'm only familiar with one ARM pipeline -- worse
yet, it's one that isn't in arm.md :(

What I've done with other ports is to have completely disjoint functional
unit descriptions for each chip in the family (unless two are nearly 
identical).

In some ways it's easier to deal with for the kinds of stuff Cygnus handles
on a regular basis (new targets under NDA during development).  But some
aspects of how the arm port works are nice too -- like the ldsched stuff.

ie make functional unit descriptions dependent on features of a particular
target.  But it gets interesting when targets have the same general features,
but differ in the precise definitions (like different issue & result
latencies).


jeff