Boris Boesler <baembel@xxxxxx> writes: > 1) As far as I can see some levels of optimization do not schedule > the code. To generate correct code I have to insert NOP-operations to > fill the delays (the architecture has no interlocks), but I can't > find a function/hook to generate these NOPs. Could someone point me > to the functions in the internals document? I tried > TARGET_SCHED_DFA_NEW_CYCLE but this one can't write to the output. > 2) The scheduling depends on the producer/consumer. An operation > can consume a register-operand without any difficult scheduling: > > cycle 1: MOV R1, #4711 ;; r1 := 4711 > cycle 2: ADD R1, R1, R1 ;; r1 := r1 + r1 > > But if an operation reads the memory via an address register, then > the register must be written some cycles before the operation: > > cycle 1: MOV A1, _label_a ;; get address of var a > cycle 2: NOP > .. > cycle 5: ADD (A1), (A1), (A1) ;; *a := *a + *a > > I tried to solve this with (define_bypass 4 ..) with my own guard- > function, but the ADD-operation appears before cycle 5 (same problem > as no.1?) gcc is weak on VLIW support. The scheduler does not insert NOPs for you. The usual workaround is to write code in TARGET_ASM_PROLOGUE which does it. E.g., frv_pack_insns in config/frv/frv.c. Ian
