🚀 go-pugleaf

I am using gcc 2.3.1 to schedule code for a variant of the R4000
that includes two types of loads/stores:

load/store		; take 1 cycle  in function unit "memory" 
load_type2/store_type2	; take 2 cycles in function unit "memory" 

Thus, any type of load/store that immediately follows a _type2 causes
a structure hazard in the memory unit.

I created the following description of the function unit "memory":

  (define_function_unit "memory" 1 0 (eq_attr "type" "load_type2,load")
    2 2 [(eq_attr "type" "load_type2,store_type2")])
	
  (define_function_unit "memory" 1 0 (eq_attr "type" "store_type2,store")
    1 2 [(eq_attr "type" "load_type2,store_type2")])
	
I also added the constraint T and a subroutine to test for T in the
machine description, as shown in the following example:

  (define_insn "movsi_usw"
    [(set (match_operand:SI 0 "memory_operand" "=T,=R,o")
       (unspec [(match_operand:SI 1 "reg_or_0_operand" "dJ,dJ,dJ")] 0))]

	<unmodified code deleted>

   [(set_attr "type"     "store_type2,store,store")
    (set_attr "mode"     "SI")
    (set_attr "length"   "2,2,4")])

For this example case, an instruction matching constraint T is 
classified as a store_type2. From a -dp debugging dump, type2 
loads/stores seem to be correctly classified.  However, these changes 
have zero effect on the code scheduling.

Is this approach valid?  Are there other valid approaches to this or a
similar problem?  Are there known bugs with the new code scheduler that
might cause this modification to have no effect?

Any assistance would be appreciated.

Timothy Kong
kong@eecs.ucdavis.edu